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(57) Abstract 

An Internet-protocol based anonymous trading system which enables traders to identify bids and offers which they are eligible to 
trade based upon a color coded methodology which gives the O^r cnsdit prcfcrcncc information about the potential counterparty while still 
maintaining the anonymity of the potential counterparty. To that end, each bid or offer is prescreened against all possible counterparties* 
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SYSTElVIS,.METHODS AND COMPUTER PROGRAM PRODUCTS 
FOR ELECTRONIC TRADING OF FINANCIAL INSTRUMENTS 

5 FIELD OF THE INVENTION 

The present invention generally relates to brokerage systems and methods, 
and more particularly, to the electronic trading of financial instruments such as 
derivatives. 

10 BACKGROUND OF THE INVENTION 

In recent years, commodity exchanges have become more and more 
dependent upon electronic trading systems. The older manual methods by which 
trades were conducted have given way to advanced computer systems that have 
generally mimicked the manual methods of old. These relatively new electronic 

15 trading systems have many advantages over the manual systems, including the 
abiUty to provide such features as greater accuracy, reduced labor cost, real time 
market information, more efficient communications over greater distances, and 
automated record keeping. However, because the markets in which these 
conunodities are being traded are so vastly different from the descriptions of the 

20 instruments to the transaction methodologies, electronic trading systems are 
generally limited to a specific market such as futures, cash, oil, stock, securities, 
etc., and sometimes even to a specific commodity within a single market. 

An example of one such automated trading system designed for the 
anonymous tradmg of foreign currencies is described in U.S. Patent Nos. 

25 5,077,665 and 5,136,501, both issued to Silverman et al, and assigned to Reuters 
Limited of London. In the Silverman et al system, a single central host 
computer maintains a central database that may consist of the trading instruments 
available for trade, credit information, and various bids and offers that are 
present throughout the system. The host con^)uter may then use this information 

30 to match active bids and offers based on matching criteria which may include the 
gross coimterparty credit limit between counterpanies to a potential matching 
transaction, price, and available quantity. To that end, each client site may 
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establish, and may subsequently vary or reset, a credit limit for each possible 
counteiparty. The credit limits may be used by the host computer to establish the 
gross counterparty credit limit for each possible pair of parties and which niay be 
equal to the mininrnm of the remaining credit {Le., initial credit limit less any 

5 applicable transactions that have aheady been executed) from a first party to a 
second party and from the second party to the first party. The host computer 
may block completion of an otherwise eligible matching transaction between a 
given pair of potential counterparties when the transaction has an associated value 
in excess of the applicable gross credit limit. In the Silverman et al, system, the 

10 various client site computers (also referred to as keystations) merely maintain and 
display a restricted subset of the information available at the host computer such 
as a predetermined number of the best bids and offers, and conmiunicate credit 
and other transaction orientated information to the host conq)uter for execution. 
However, in an attempt to preserve the anonymity of the parties, the client sites 

15 may not have access to the credit limits set by their possible counterparties, or 
even to the identification of any other party to a particular transaction until after a 
transaction has been completed. 

Thus, in the Silverman et aL system, confidential counterparty credit limit 
data is apparently maintained and utilized as part of the trade matching process 

20 by the central host computer. As a consequence, each client site may not have 
the abiUty to determine, prior to committing to buy or sell at a displayed price 
from one or more anonymous counterpanies, whether it is in feet eligible to 
respond to any of the bids or offers currently being displayed. Further, the credit 
limit appears to be merely a cap value (or credit line) on the amount of trading 

25 one party will enter into with another party. It has little to no relationship to the 
credit risk the other part>^ represents since the financial commitment associated 
with the financial instruments traded with this system ends at the consummation 
of die underlying contract. Thus, a cap value may be sufficient in this particular 
circumstance. The central host computer may not utilize the credit information 

30 until after a match has been found between counterparties to determine if the 
counterparties have sufficient credit with one another to execute the trade. 
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Consequently, unless a trader attempts to execute a trade at die best price 
currently displayed on the trader's screrai, the trader using one of the anonymous 
matching systems may not Icnow whether the trader has credit with, and is willing 
to extend credit to, the anonymous counterparty offering {i.e., bidding) the best 

5 price currently displayed on the trader's screen. Thus, the trader does not ioiow 
whedier any attempt to buy or sell at the displayed price may be subsequendy 
mvalidated by the system for lack of such credit. The Silverman et al system 
also fails to provide for dialogue between the parties, much less anonymous 
dialogue which may faciliute the execution of a trade that might otherwise not 

10 occur. 

Reuters Limited has apparently expanded the system described in 
Silverman et al. to include Forward Foreign Exchange contracts which are 
derivative instruments. However, as opposed to offering a settlement risk system 
that enables credit analysis prior to face-to-face setdement, the Reuters Limited 

15 system introduces die concept of soft matching which makes trades on the basis 
of credit risk raflier dian settlement risk. Thus, a trade is not confirmed until 
both parties obtain subsequent credit approval. Eidier party can cancel the 
transaction under the guise of no credit available to the counterparty once diey 
know who is the counterparty. Accordingly, the Reuters Limited system is 

20 reportedly an unpopular solution to derivative trading via an electronic trading 
system. 

Another automated trading system is disclosed in U.S. Patent No. 
5,375,055 issued to Togher et al. and assigned to Foreign Exchange Transaction 
Services, Inc. The Togher et al system is an anonymous trading system which 

25 may identify the best bids and offers from those counterparties widi which each 
client site is currentiy eligible to deal, while maintaining the anonymity of the 
potential counterparty and the confidentiality of any specific credit limitations 
imposed by the anonymous potential counterparty. This system is apparentiy 
designed to nm as a closed system, witii dedicated desktop terminals connected to 

30 various local computer centers, which are in turn connected to regional 
conq>uters. 
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In the Togher et al. system, each client site may only be able to view one 
foreign currency at a time per screen. The Togher et al. system is further limited 
by the fact that each client site may provide the system with only limited credit 
information for each potential counterparty (for example, a one bit flag indicating 

5 whether a predetennined limit has already been exceeded), and by the fact that 
each bid or offer for a particular type of fmancial instrument is apparently 
prescreened by the system for conq)atibility with that limited credit information 
before calculating an anonymous dealable price for presentation to the traders 
dealing with that particular fmancial instrumem. llie prescreening in Togher et 

10 ai is a simple check to determine whether any credit remains between the two 
counterparties to the potential u^action, and thus may be performed using a 
single yes/no preauthorization matrix. 

The preauthorization matrixes may be maintained at each of the several 
regional nodes (also referred to as distributed nodes) of a distributed processing 

15 communication network, with each such regional node being connected by 
corresponding individual links of the communications network to the respective 
client sites for which it is responsible for distributing market information 
including customized dealable bid and offer prices, and global best prices. 
The sensitive credit limit data indicating how much credit a particular 

20 client site is willing to extend to each possible counterparty is preferably 

maintained at an access node associated with that particular client, and a simple 
yes/no indication of whether the entity (for example, a trader, a trading floor, or 
a bank) associated with that particular client site is willing to transact business 
with a particular counterparty is transmitted to the other nodes of the 

25 communications network. 

To fimher limit the data received and processed by each of the relevant 
regional node computers {i.e., the regional nodes closest to the particular client 
site and/or closest to the particular counterparty), merely the changes in the 
credit state between a particular client site and a particular counterparty {i,e, , that 

30 credit is no longer available or credit is now available) may be transmitted to the 
distribution nodes, and any credit state information relevant to transactions 
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between two client sites both associated with other distribution nodes may be 
altogether ignored. 

In the Togher et ai system, if either of tiie two applicable credit limits 
has not previously been exceeded between a particular pair of counterparties, 

5 then the system displays the entire bid or offer as a dealable transaction, but 
apparently permits each client site to block any above-limit portion of any 
resultant buy or sell transaction during a subsequent deal execution/verification 
process. This may, however, add additional time consuming steps for the users of 
the Togher et al. system. Alternatively, possibly at the option of the party by or 

10 for whom the low limit has been set, the entire transaction may be blocked. As a 
second alternative, a preauthorization matrix may indicate whether sufTicient 
credit remains to execute a predetermined standard deal amount in addition to, or 
instead of, a mere indication as to whether any credit from a particular potential 
counterparty had aheady been used up. In such an alternate embodiment of the 

15 Togher et al. system, it might also be possible to display to each trader two 
dealable prices: one at which at least the predetermined standard amount is 
available, and a second one at which only a small amount may be available. 
Thus, individual orders are not independently treated, and the user may not have 
the ability to look through the bids and offers and deal at a worst price, if the 

20 user so chooses because of a difference in counterparties credit qualities. 

In accordance with another aspect of the Togher et al. system, at least a 
first trader having an open quote that is displayable as the best dealable or regular 
dealable quote at any of the other trading floors is automatically alerted that their 
bid (offer) quotation is the best price available to at least one potential 

25 counterparty with whom munial credit exists, and thus could be hit (taken) at any 
time. Similarly, at least if the quoter's bid (offer) quote is not currently the best 
with at least one trading floor but is thus subject to immediately being hit (taken) 
by a trader at that trading floor, then the quoter is preferably also alened if 
his/her quote is joined (z.e., equal to in price, but later in time) to such a best 

30 dealable or regular dealable price from another trading floor. In other words, in 
the Togher et al. system, the auto-matching process does not enable the active 
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trader to select a price other than the best price to trade. This may force the 
trader to accept what the system offers, even if the trader would prefer a different 
counterparty for credit reasons. In addition, the Togher et al. system does not 
show the trader the total depth of the market, only those prices which are 
5 dealable, and thus, may fail to give the trader a complete picture of the market. 
The trader is also limited to the quantity stated. No provision is made for the 
modification or negotiation of the quantity or other terms of the trade. 

The systems described above are such that diey focus on overnight 
settlement risk. These systems are apparendy incapable of dealing with the 

10 actual credit requirements of a variety of different individual financial 

instruments simultaneously, or a counterparty's long-term ability to meet these 
requirements. As a result, diese systems generally have only been deployed in 
the markets where settlement takes place in a few days of the transaction, and 
there are no continuous and ongoing credit requirements or obligations between 

15 the counterparties. Specifically, as a result of these limitations, these designs 
may not be able to support the anonymous trading of financial instruments such 
as interest rate swaps, caps and many other fmancial products. They may be 
unable to accommodate these more complex fmancial instruments because, 
among other things, these systems apparently treat all financial instruments alike, 

20 and therefore, may be incapable of handling more complex financial instruments 
which require a determination about the fmancial strength of the opposing 
counterparties. Trades conducted with some financial instruments such as 
derivatives create multi-year financial commitments, and therefore, mere credit 
limit or credit cap systems are insufficient in measuring and managing an 

25 institution's credit risk. 

Accordingly, it is noted that no known system is designed to operate with 
derivative products such as interest rate swaps, caps, floors, forward rate 
agreements (FRA), interest rate basis swaps, interest rate options, foreign 
exchange, switches, or any other over the counter derivative instruments. 

30 Derivatives are considered by many to be too complex to be efficiently handled 
within an electronic trading system. Specifically, derivative products are 
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typically define by certain teims and conditions, and the different types of 
derivatives products are defined by different sets of terms and conditions. For 
example, an FRA is generally defined by a start time, an end time, an over date, 
and a floating rate option, while an interest rate swap is generally defined by a 

5 start time, an end time, an over date, a floating rate option, a frequency of the 
fixed coupons, a basis, and a special rule(s) as applicable with some currencies. 

Accordingly, the variances in the specific information necessary to 
adequately define the different derivative products has apparently been a 
deterrence to the development of an electronic derivatives trading system. 

10 Traders of derivative instruments have thus been relegated to verbally explaining 
all the terms and conditions of the instruments that are subject of a transaction to 
ensure that the parties to the transaction are adequately informed as to the terms of 
the instrument being traded. 

A further limitation of the known electronic trading systems which has 

15 contributed as a deterrence to their application to the derivatives market is the 
absence of an acceptable credit screening process of potential counterparties in a 
maimer which accommodates the nuances of the derivatives market. While many 
of the prior art electronic trading systems such as the ones described above provide 
a credit screening feature, they typically only track the amount transacted between 

20 two parties, and iqjon each transaction between the two parties, reduces the 

available amount according to the amount of the transaction. Thus, the credit risk 
measured by these systems is based on the principle or quantity of the transaction. 
No consideration is given to the future obligations under the contract. 

In the derivative market, a counterparty's credit position may vary with 

25 each new transaction conducted with other parties. The prior art systems do not 
account for such changes in a counterparty's position. Further, the credit qualities 
associated with derivative products are generally more complex dian most other 
financial instruments. For example, a particular trader may be willing to trade with 
a particular counterparty on one type of financial instrument but not another. 

30 Further, a trader may accept that one type of financial instrument but only for a 
certain length of time (/.e., maturity). 
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Yet another deterrence is the difficulty of detennining a trader's position 
{i.e., interest risk position), and then identifying potential counterparties with 
offeetting positions for initiating a transaction. No known electronic trading 
system has been able to do this on a real-time basis. In particular, a large new 
5 market has recently emerged as a resuh of interest rate sw^ dealer's needing to 
better manage the risk associated with changes in interest rates on their Interest 
Rate Swap portfolios. As these markets have become more competitive, and the 
bid-offer spreads have narrowed considerably. This factored with the wide spreads 
of exchange traded Eurodollar futures has made the use of exchange traded 
10 contracts for hedging short-term risks expensive and sub-optimal. As a result, the 
switch was created. A switch is simply the simultaneous purchase and sale of a 
pair ofsimUar Forward Rate Agreements. This instrument along with the mutually 
ofisetting needs of derivative portfolio risk managers provides a perfect risk 
management tool for a large portfolio of Interest Rate Swr^s. 
15 Despite the obvious advantages and demand fcom risk managers, the 

complexity and time consuming nature of con^leting a transaction has resulted in 
this market growing rather slowly. Risk managers arc generally very wary of 
disclosing the exact nature and size of their own portfolios. Therefore, finding a 
counterparty that has an opposite need is often difficult. It is a time consuming and 
20 cosUy task to coUect the market information needed to determine a specific trader's 
ovm position within the market, much less to be able to identify potential 
counterparties with offsetting positions. This is currently done manually by voice 
brokers who prepare and send faxes Usting days that a cUent needs to buy or sell, 
but the amount or importance of any date is not provided. This fex goes to other 
25 voice brokers and institutions and begins a process which involves multiple faxes 
sent back and forth until a deal is finally negotiated. This deficiency of the prior 
art systems strikes to the essence of the derivatives market which is based upon 
large financial institutions to being able to manage their credit risk on a daily basis. 

SUMMARY OF THE INVENTION 
30 The present invention comprises systems, methods, and conq)uter 

program products that provide for electronic trading based on the client/server 
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model, including a central processing center (i.e., server) having multiple server 
modules and a plurality of individual trader workstations (i.e. , clients), all of 
which are operationally interconnected, preferably via an Internet-protocol 
network. Because of the open architecture of the system, it is possible that the 
5 systm may run widiin the context of an Internet browser on a user's existing 
desktop computer. At the user's workstation, the user may select from a variety 
of different interfaces that enable the user to follow markets, enter and execute 
trades, and monitor outstanding and historical orders and executions. Thus, the 
user is provided an in-depth view of the market and essentially con:5)lete control 
10 over the order load process. 

The market information provided to the user is coded with credit 
preference data generated by referencing the complex credit preferences mputted 
by each user regarding all possible counterparties. Thus, potential counterparties 
are then able to identify which orders they are eligible to trade based upon the 
15 coded credit preference data. The user is also provided widi a feature whereby 
the user can input an interest reset risks portfolio into the system and then view 
his/her interest rate reset risk position relative to other counterparties that have 
inputted their respective interest rate reset risks portfolios in order to determine 
possible offsetting positions. Hxe user is also provided with a facility for placing 
20 orders for various financial instruments via an auction process whereby the 
system automatically matches all orders and determines the prices and quantities 
executed based on several guidelines including user credit preferences. In 
addition, the user is provided with a switch auction facility whereby the user can 
use the auction process to trade forward rate agreement (FRA) switches with 
25 other counterparties utilizing the same credit preference screening. 

At the central processing center, multiple server modules operate 
simultaneously to perform various functions such as delivery of market 
information to the user, credit preference verification of a requested trade, 
execution of trades, term negotiation, acknowledgments, position discovery, and 
30 auction execution. The central processing center also includes a database which 
provides persistent storage of information such as historical data, mstrument 
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definitions, user credit preferences, user and business unit data, and historical 
market data. 

At the trader woritstations, multiple software modules operate 
simultaneously to perform various functions at the fixmi end of the system such as 
5 providing user interfaces, performing credit preference verification, and 

receiving iapaned user data such as trade data and credit preferences. The trader 
workstations are preferably implemented on desktop computers of the users via 
an Internet browser program, and therefore, do not require dedicated terminals 
on the users' desktops. The communication between the trader workstations and 
10 the central processing center is preferably based on Internet Protocol (IP), and 
operates over the Internet in a secure mode. 

In accordance with an aspect of the present invention, a system for 
fecilitating derivative trading comprises a communication network 
interconnecting a first user and a second user to a central processing center, and a 
15 market inventory module associated with the central processing center that 
provides the first and second users with essentially real-time order information 
regarding more than one financial instrument, wherein the order infonnation 
includes requests to buy financial instniments and requests to sell financial 
instruments. In addition, the system may include a trader module associated with 
20 each of the first and second users for receiving the real-time order information 
from the central processing center and for presenting the real-time order 
infonnation to ttie first or second users according to respective user customized 
profiles. The system may fiirther include a credit preference module associated 
with each of the first or second users, wherein the credit preference modules 
25 indicate the trade eligibility of the respective first and second users for each 
request to buy or sell. In addition, the system may comprise an execution 
module associated with the central processing center fliat processes a trade 
initiated by one of either tiie first or second users which desires to trade on an 
order posted in tiie order information by the other of the first and second users. 
30 In essence, the execution module processes the term negotiations and 
will-do-more services. In addition, tiie system may comprise a setdement 
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module associated with the central processing center for processing transactions 
and generating confirmation notices, which are submitted to both parties. The 
settlement module also calculates the conmiission fees. 

In accordance with another aspect of the present invention, a system for 
5 facilitating derivative trading, wherein the system ihchides a plurality of 

interconnected user nodes configured to exchange order information via a central 
processing center. The central processing center may comprise a first user node 
includitig a trader module that receives real-time order information and presents 
the real-time order information to a user according to the customized profiles 
10 defined by a first user, a credit preference module that includes credit prefereiK:e 
dau inputted by die first user for use in determining trade eligibility of trades 
proposed m the real-time order information with a second user, and an interface 
to a communications network tiiat interconnects the plurality of user nodes. Each 
user node may further include a switch module that receives interest rate swap 
15 positions bom die first user and die second user, and tiiat determines relative 
position information for die first user. 

In accordance with yet anotiier aspect of die present invention, a system 
for facilitating derivative trading, wherein such system includes a plurality of 
interconnected first and second users that exchange order information, and 
20 wherein each of the first and second users are connected to a central processing 
center. The central processing center may comprise a group server tiiat provides 
die first and second users widi essentially real-time order information regarding 
more dian one financial instrument. The order information preferably includes 
requests to buy financial instruments and requests to sell financial instruments. 
25 The central processing center may further comprise an execution module that can 
process a trade initiated by one of eidier die first and second users which desires 
to trade on an order proposed in the order information by the odier of die first 
and second users. This central processing center may further include an interface 
to a communications network tiiat interconnects die plurality of first and second 
30 users to die central processing center. 
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In accoidance with another aspect of the present invention, a subject-based 
addressing scheme comprises a four-part subject code that includes a source field, a 
class field, a symbol field, and a currency field. The four-part subject code is 
derived by systematically dividing the perimeters, terms, and conditions of the 
5 various derivative instruments into four discreet parts. The source field identifies 
the souree of the information, which in most cases will Derivatives Net, Inc., the 
assignee of the present application. Tlie class field identifies a principal product 
class into which the financial instrument faUs. The symbol field provides the 
underiying structure of the derivative instrument, thus, is the principal code used to 
10 define each instrument. For each class, an identified list of perimeters are included 
in the symbol field for defining the derivative instrument. TTie currency field 
provides the currency code of the instrument, preferably utilizing the standard ISO 
currency code. 

To faciUtate more efficient referencing of instruments that are commonly 
15 used by traders, aliases will be provided for the more commonly utilized 

instruments. The alias is an abbreviated version of the four-part subject code. The 
alias wiU allow traders to quickly identify and reference derivative instruments 
without the lengthy verbal explanation of the terms and conditions of a derivative 
instrument, as required with verbal trading systems. Thus, the subject based 
20 addressing of the present invention enables the electronic trading of derivative 
instruments utilizing standard unifomi symbols that wUl enable traders to encode 
the complex temis and conditions of a derivative instrument into a symbol utilizing 
little data. 

In accordance with another aspect of the present invention, a credit 
25 monitoring system forms a complex check to determine if two particular 
counterparties will accept each other for a particular trade based upon their 
respective predefined credit preferences. In accordance with an embodiment of the 
present invention, credit preferences inputed by each counterparty with regard to 
the other counterparty are referenced to determine the trade eligibility of either 
30 party with respect to the other for a particular financial transaction instrument, 
indication of >^i.ether a counterparty can enter into the proposed nrade is conveyed 

-12- 

SUBSTITUTE SHEET (RULE 26) 



PCr/US9OT1518 

WO 99/19821 

to the respective trader, preferably using a color coding scheme in which various 
colors represent the relevant credit status with regard to the viewing trader. The 
complex check performed by the system may be embodied in a simple yes/no 
statement, in terms of maturity of a particular fimmcial instrmnent, or in terms of a 
5 risk quotient (/.e., risk equivalent or RQ) initiaUy deteimined by the system, 
though modifiable by the trader. Accordingly, financial institutions which trade 
complex financial instruments such as derivatives which create obligations which 
extend into the future may better monitor their credit risk by the bilateral credit 
screening of the present invention. Particularly, the multilevel credit preferences 
10 which each trader may utilize in establishing credit preferences with regard to other 
counterparties enables greater control and flexibUity in the trading of complex 
financial instruments. It is further noted that the credit check process is performed 
anonymously so as not to identify potential counterparties to a deal until after the 

trade is agreed to by both parties. 
15 In accordance with another aspect of the present invention, a switeh 

engine module receives interest rate risk portfolios from a plurality of traders, 
and for each prospective trader, provides available switches based on positions in 
other counterparty portfolios that offeet the viewing traders' positions. The 
offsetting positions are encoded with credit preference information in order to 
20 identify eligible trades based on both counterparties credit preferences. Whereas 
switch position discovery is often a labor intensive and expensive task, it is now 
performed.virtually instantaneously by the switeh engine module of the present 
invention. Further, an embodiment of the present invention provideis for a switch 
auction whereby users can use an auction process to trade for forward rate 
25 agreement switches with other counterparties. In the switeh auction, the price is 
predetermined by the system prior to the auction so that parties can opt out of the 
transaction if desired. The credit preferences of the participating traders are 
taken in consideration in making matches. 

Other feamres and advantages of the present invention will become 
30 apparem to one that is skiUed in the art upon examination of the following 

drawings and detaUed description. It is intended that all such additional feamres 
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and advantages be included herein within the scope of the present invention, as 
defined in the appended claims. Further, it will be appreciated by those of skill 
in the art that the above-described systems of the present invention may be 
provided as m^ods or computer readable program means. 

5 

BRIEF DESCRIPTION OF TBE DRAWINGS 

FIG, 1 is a schematic diagram of a computer network implementing an 
electronic trading system in accordance with an embodiment of the present 
invention. 

10 FIG. 2 is a block diagram illustrating the architecture and functionality of 

a central processing center in accordance with an embodiment of the present 
invention. 

FIG. 3 is a block diagram illustrating the architecmre and functionality of 
a trader system in accordance with an embodiment of the present invention. 
15 FIG. 4 is a block diagram illustrating the architecture and functionality of 

a business unit proxy in accordance widi an embodiment of the present invention. 

FIG. 5 is an example of a command center interface. 

FIGs. 6A-6B are exan^)les of difSerent tabbed partitions of a user 

preference interface. 
20 FIG. 7 is an example of a credit preference setting interface. 

FIGs. 8A and 8B are examples of different tabbed partitions of a modify 

credit groups interface. 

FIGs. 9A and 9B are examples of the new binary interface and complex 
preference interface respectively, which are accessible from the credit preference 

25 setting interface. 

FIG. 10 is an example of a business unit information interface. 

FIG. 11 is an illustration of the credit preference logic of an embodiment 

of the present invention. 

FIG. 12 is an example of a market entry interface. 
30 FIG. 13 is an exanq)le of a symbol definition interface. 

FIG. 14A is an example of an passive order interface. 
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FIG. 14B is an exan^)le of an hit order interface. 
HG. 15 is an example of a maricet detail interface. 
FIG. 16 is an example of an outstanding order blotter interface. 
FIG. 17 is an example of a client monitor interface. 
5 FIG. 18 is an example of a execution notification and quantity negotiation 

interface. 

HG. 19 is an example of a term negotiation interface. 
FIG. 20 is an example of a user position portfolio interface. 
FIG. 21 is an example of a switch interface. 
10 FIGs. 22A and 22B are examples of an auction interface and a switch 

auction interface, respectively. 

FIG 23 is an example of a main screen interface in accordance with an 
embodiment of the present invention. 

FIG. 24 is a flowchart of the credit preference feature in accordance with 
15 an embodiment of the present invention. 

FIG. 25 is a flowchart of the subject based addressing feamre in 
accordance with an embodiment of the presem mvention. 

FIG. 26 is a flowchart of the execution of a trade in accordance with the 
embodiment of the present invention. 
20 FIGs. 27 A and 27B are flowcharts of a trade execution from the 

perspective of the user posting the order and the user acting on die order, 
respectively, and in accordance with an embodiment of the present invention. 

HG. 28 is a flowchart of the position discovery feature in accordance 
widi an embodiment of the present invention. 
25 HG. 29 is a flowchart of the auction feature in accordance witii an 

embodiment of the present invention. 

HG. 30 is a detailed flowchart of die auction feature in accordance with 
an embodiment of the present invention. 

HG. 31 is a flowchart of the calculation of the average auction price in 
30 accordance with an embodiment of the present invention. 
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FIG. 32 is a flowchart of the matching performed in an auction in 
acconiance with an embodiment of the present invention. 

FIG. 33 is a flowchart of the validation of a resulting order in an auction 
in accordance with an embodiment of the present inv^ition. 
5 FIG. 34 is a process flow diagram illustrating operations and functionality 

of the central processing center in accordance with an embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

10 The present invention now will be described more fully hereinafter with 

reference to the accompanying drawings, in which preferred embodiments of the 
invention are shown. This invention may. however, be embodied in many 
different forms and should not be construed as limited to the embodiments set 
forth herein; rather, these embodiments are provided so that this disclosure will 

15 be thorough and complete, and will fully convey the scope of the invention to 
those skilled in the art. Like numbers refer to like elements throughout. 

I. Introduction 

The following description is of a best-contenq)lated mode of carrying out 
20 the present invention. The systems, methods, and computer program products of 
the present invention have practical apphcation in anonymously trading a very 
broad cross-section of credit-sensitive, bilateral financial instruments. However, 
a particular application of the present invention described hereinafter is directed 
to the use of the present invention for trading financial instnunents in the 
25 derivatives market. The scope of the present invention should not be limited to 
that described hereinafter, but should be determined by referencing the appended 
claims. 

The present invention provides for a standardized contract definition, and 
means for matching complex credit preferences of each counterparty before a 
30 trade is executed. Therefore, potential counterparty users are able to identify 
bids and offers that they are eligible to trade based on credit preference 
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information provided before initiating a trade. The present invention also 
permits users to place passive orders (bids or offers on the various financial 
products for otter counterparties to actively choose from to hit (bids) or lift 
(offers), without the posting user doing anything further) or active orders (where 

5 the viewing user actively initiates the trade by selecting passive bids or offers 
which are already in the system). This gives a user maximum control over the 
order flow process. For instance, fliere may be a situation whereby the bids in a 
particular market are higher than the ofiers, but no trading is taking place. This 
situation may occur when the credit quality of the best offer (which in this case 

10 would be below the bid) would not be good enough for a bidder to be willing to 
enter into a transaction with that counterparty. This is a significant difference 
from the prior art systems in which orders are automatically matched if the prices 
are equal because such prior art systems typically limited the user's control over 
the order flow. 

IS The present invention also provides fmancial markets with electronic 

trading systems and methods for identifying possible counterparties and executing 
trades for forward rate agreement (FRA) switches and other financial products. 
The present invention further provides the ability for the users to place orders for 
various fmancial instruments via an auction process that can be one-to-many or 

20 many-to-many, whereby the system automatically matches all orders and 

detennines the prices and quantities executed on the basis of several guidelines or 
parameters. A further feamre of the present invention is an auction trading that 
is available to users, whereby users can use an auction process to trade FRA 
switches with the other counterparties. This form of auction is referred to 

25 hereinafter as a switch auction. In the auctions, the price is prefierably pre- 
determined by the system prior to the auction taking place. The prices 
determined by the system are referred to. hereafter as the fair price. 

The systems and methods of the present invention are designed to reflect 
the fact that fmancial institutions operate under many different stnicmres. In 

30 order to accomplish this, the following concepts/defmitions are provided: 
Legal Entity (LE): 
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This is the incorporated entity in which contracts are 
negotiated on behalf of by users (traders) of the system. 
Business Unit (BU): 

This is a grouping of individual users within a Legal Entity 
S that act together and share attributes such as LE, manager, 

address, 

settlement information, credit preferences (see below), etc. 
Risk Equivalent (RQ): 

This is the unique measure of Risk associated with fmancial 
10 contracts such that contracts with different attributes can be 

compared on a like basis for credit risk purposes. 
Credit Preferences (CP): 

This is the model which allows the system to handle 
different measures of risk equivalent used by different 
IS institutions and different financial contracts, all with 

different internal structures. 
Classes of Financial Instruments (CL): 

These are collections of fmancial contracts which share 
simiiar attributes. 
20 Credit Groups (CG): 

A method to allocate credit preferences across classes of 
fmancial contracts. 
User Preferences (UP): 

A method to allow institutions or users to control or 
25 manage access to the functions within the system. 

Filters (FI): 

These allow users to limit the messages (i.e. , request for 
price or request for switch they receive or view. 
Symbology (SY): 

30 This enables users to quickly and easily reference financial 

contracts within the system in a systematic manner. 
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Term Negotiation (TN): 

This is a method which allows users to negotiate non- 
commercial terms of contract subsequently to a trade. For 
example, the exchange of bonds relating to a spread trade. 
5 Credit Over-Ride Process: 

This process enables a user to disclose his/her identity to a 
counterparty to see if they will accept a trade with him/her 
even though they initially refused him due to credit issues. 

Comprehensive Confirmations: 
10 This is a confirmation lay-out in order to fiilly define 

bilateral contracts across any classes of financial 
instruments. 

Request For (RF) 

This is a method to broadcast to the other users (subject to their 
IS FI) an interest in a price or market. 

II. System Architecture 

As will be appreciated by one of ordinary skill in the art, the present 
invention may be embodied as a method, a data processing system, or a computer 

20 program product. Accordingly, the present invention may take the form of an 
entirely hardware embodiment, an entirely software embodiment or an 
embodiment combining software and hardware aspects. Furthermore, the present 
invention may take the form of a computer program product on a computer- 
readable storage medium having computer-readable program code means 

2S embodied in the storage medium. Any suitable computer readable storage medium 
may be utilized including hard disks, CD-ROMs, optical stomge devices, or 
magnetic storage devices. 

The present invention is described below with reference to block diagrams 
and flowchart illustrations of methods, apparatus (i.e., systems) and computer 

30 program products according to an embodiment of the invention. It will be 

understood that each block of the block diagrams and flowchart illustrations, and 
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combinations of blocks in the block diagrams and flowchart illustrations, 
respectively, can be implemented by computer program instructions. These 
computer program instructions may be loaded onto a general purpose computer, 
special purpose computer, or other programmable data processing apparatus to 

5 produce a machine, such that the instructions which execute on the computer or 
other programmable data processing appdidXws create means for implementing the 
functions specified in the flowchart block or blocks. 

These computer program instructions may also be stored m a computer- 
readable memory that can direct a computer or other programmable data 

10 processing apparatus to function in a particular manner, such that the instructions 
stored in the computer-readable memory produce an article of manufacture 
including instmction means which implement the function specified in the 
flowchart block or blocks. The computer program instructions may also be loaded 
onto a computer or other programmable data processing apparatus to cause a series 

15 of operational steps to be performed on the computer or other programmable 
apparatus to produce a computer implemented process such that the instructions 
which execute on the computer or other programmable apparatus provide steps for 
implementing the functions specified in the flowchart block or blocks. 

Accordingly, blocks of the block diagrams and flowchart illustrations 

20 support combinations of means for performing the specified functions, 
combinations of steps for performing the specified functions and program 
instruction means for performing the specified functions. It will also be 
understood that each block of the block diagrams and flowchart illustrations, and 
combinations of blocks in the block diagrams and flowchart illustrations, can be 

25 implemented by special purpose hardware-based computer systems which perform 
the specified fimctions or steps, or combinations of special purpose hardware and 
computer instructions. 

A trading system in accordance with the present invention is an electronic 
brokerage system which may use Internet protocol-based communications 

30 networks for fecilitating the trading (/.e. , buying and selling) of financial 
derivatives by users, each of which is associated with the user*s own desktop 
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computer system (trader system) located on the trading floor of a financial 
institution (client site), as described below. At the user's desktop computer 
system, the present invention is preferably implemented by a Java-based software 
program, though odier suitable program languages can be utilized such as 

5 dynamic hypertext markup language (DHTML). C + or C + + . 

As shown in FIG. 1 , a trading system 10 in accordance with the present 
invention comprises a central processing center 12 which is in communication 
with the client sites 14 via one or more of a variety of Internet protocol based 
networks 16. By way of illustration, a private extranet, a public Internet, and a 

10 third party extranet are show, though it will be recognized by those skilled in the 
art that other networks such as the Public Switch Telephone Network (PSTN) 
may be implemented as a network 16. Further, by having multiple networks 16 
available, the user is provided redundancy in case one network experiences a 
service interruption, and the user is able to choose between the several networks 

15 16 for primary access based on factors such as toll charges or bandwidth. 

Each client site 14 includes one or more business unit servers 18 which, 
among other things, can store copies of the Java ^lets which can be utilized to 
implement the present invention. The business unit servers 18 may also perform 
encryption/decryption functions for messages that are received and sent over the 

20 networks 16. The business unit servers 18 are preferably connected to the client 
sites 14 internal data network. Thus, one or more trader workstations 20 may be 
connected to a business unit server 18 of a client site 14. Accordmgly, a user's 
own desktop conq)uter which is connected to the client's internal data network 
may function as a trader workstation 20 and nm the Java-based software of the 

25 present invention to enable interaction with other trader workstations 20 via the 
central processing center 12. 

With reference to FIG. 2 , illustrated is the central processing center 12 
which includes a trade mechanism 30, a group server mechanism 32, auction 
mechanism 34, and a switch mechanism 35, all in accordance vnlh the present 

30 invention. The trade mechanism 30 includes several modules including a market 
inventory module 38, an execution module 40, and a settlement module 42. The 
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market inventory module 38 holds the passive orders for each market and 
broadcast the same to the trader workstations 20 when new orders are received, 
validates any proposed trade, performs a second and final credit preference check 
that cannot be performed at the trader workstation 20, validates that both traders 
5 are still on-line (/. e., active), executes the trade, and sends out a status update to the 
traders. The execution module 40 receives the executed trade and proposes a trade 
for a greater quantity if applicable (referred to as the will-do-more feature), and 
processes term negotiation if applicable. The settlanent module 42 calculates the 
appropriate commission, generates the confirmation, and sends the confirmation to 

10 the two parties. 

The group server mechanism 32 interfaces the trader module 30 with the 
trader workstations 20. The central processing center 12 may include a plurality 
of group server mechanisms 32, each of which preferably serves a subset of the 
users {Le., trader workstation) of system 10, though the system 10 may be 

IS in9)lemented with only one group server mechanism 32. The group server 
mechanism 32 monitors the connection of each nader workstation 20 so that 
log-in and log-out times and usage can be monitored. The group server 
mechanism 32 also caches market information being viewed at each trader 
workstation 20 and create an order identification code that uniquely identifies that 

20 order. The credit preference information of all users is cached in by the group 
server mechanism 32 for delivery to each trader workstations 20 when the 
associated user logs in. Any changes in the credit preference setting by a trader 
are detected and forwarded to the trader workstations 20 of the other users. 

The switch mechanism 35 is configured to receive a portfolio of interest 

25 reset risk for a plurality of users and provide the users with an anonymous view 
at their relative position to other possible cotmterparties and available trades that 
may offset the user's interest rate reset risk. The auction mechanism 34 performs 
a switch auction function whereby orders or FRA*s are received from the users 
and anonymously matched based on an algorithm that takes user credit 

30 preferences into consideration. 
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The trader mechanism 30, group server mechanism 32, auction/switch 
auction mechanism 34, and switch mechanism 35 may be collectively 
in^lraented as market module 44. 

The central processing center 12 mchides a processor 50 that 
5 communicates with the other elements within the central processing center 12 
via a system interface 52. An input devise 54, for example a keyboard or a 
pointing device, is used to input data from a user, and a screen display device 
56, for example, a monitor, is used to output data to the user. A n»nory 58 
within a central processing center 12 includes the market module 44 and a 

10 conventional operating system 60 which communicates with the market module 
44 and enables execution of the market module 44 (including the trade 
mechanism 30, group server mechanism 32, and auction mechanism 34) by 
processor 50. An external communication line 62 is provided to interface the 
central processing center 12 with other computer systems or co^^)uter-based 

15 devices such as networks 16. Lastly, a hard disk 64 may be provided as a 
I^rsistence memory device, as well known to the industry. Preferably, a 
relational database 66 resides on the hard disk 64 for maintaining information 
such as current state infonnation for each trader woiicstations 20, user and 
business unit data, financial instrument definitions, order states, transaction 

20 states, confirmation states, historical confirmation and transaction data, credit 
preferences of all business units, and historical market data. Preferably a 
relational daubase 66 resides on the hard disk 64 for maintaining information 
such as current state infonnation for each trade workstation 20, user and 
business unit data, financial instrument definitions, order states, transaction 

25 states, confirmation states, historical confirmation and transaction data, credit 
preferences of all business units, aixl historical market data. Preferably, the 
relational database 66 is based on strucmred query language (SQL) management 
system, as well known in the industry. 

With reference now to FIG. 3, illustrated is an embodiment of the trader 

30 workstations 20 which includes a trader module 70 in accordance widi the 
present invention. The trader module 70 may be implemented as a componeiu 
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of a Java-capable Internet browser program 72. such as Netscape 
Comnmnicator® (Netscape Communication Company) or Microsoft® Internet 
Explorer (Microsoft Corporation) version 3.0 or higher. Thus, in a preferred 
embodiment, the trader module 70 is a Java-based program that is downloaded as 

S Java fiq>plets for each session and implemented by a Java virtual machine (JVM) 
73 within the Internet browser 72. The JVM 73 of the Internet browser program 
72 may be a stand alone software application, a plug-in application, or a helper 
application, all of which is well known in the art. The trado* module 70 includes a 
market inter&ce module 74, a credit preference module 76, a symbol module 78, 

10 switch module 80, and an auction module 81. The market interface module 74 
comprises one or more user interfeces for presenting information to the user. In 
the context of the present embodiment, a user interface is provided as a window 
within the context of the Internet browser program 72. However, a user interface 
in accordance with the present invention may take many forms such as a three 

15 dimensional virtual reality world based on virtual reality modeling language 
(VRML), an audio receiver/transmitter, or any other suitable form of inter£eu:e 
between the user and trader workstations 20. In a preferred embodiment, the 
market interface module 74 comprises a control center interface, maiket entry 
interftice, market detail interface, switch interface, and auction interface, all of 

20 which are described in more detail hereinafter. 

The credit preference module 76 receives the stored credit preferences 
inputted by the user and stored at group server mechanism 32. The stored credit 
preferences include preferences directed to the other business unit's legal entities, 
and die preferences inputted by the other users directed toward the business unit's 

25 legal entity of the subject user. As mentioned above, the credit preference 

information is preferably stored in the database 66 (FIG. 2). The credit preference 
module 76 may encode the order information being presented to the user with the 
credit preferences of the user and the credit preferences of counterparty that 
posted the order. The credit preference module 76 also performs a credit 

30 preference check for each order when a trade is initiated. Because of the potential 
complexity associated with the different types of credit methods offered by the 
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present invention, portions of the credit check process may be pof ormed by the 
market invratory module 38 of the central processing cent^ 12. The credit 
preference module 76 at each trader workstation 20 comprises a simplified matrix 
of yes's and no's, and associated maturities. If the business unit has selected an 
S even more complex mediod {L e. , complex), a unit (such as a risk quotient, i.e. , 
RQ) by maturity is also required. The trader workstation 20 will therefore not be 
able to determine whether the full quantity can be traded. Thus, the market 
inventory module 38 repeats the credit check to ensure the very latest credit 
preferences are used (in case of any lateiK^y in updating the credit preferences at 
10 the trader workstations 20) and to complete any complex credit preference check 
for quantity. 

The symbol module 78 stores the symbol definitions utilized for the 
subject-based addressing of the different financial instruments traded in the system 
10. The symbol module 78 also provides means for defining new symbols for use 

15 with the system 10. The switch module 80 is configured to receive interest rate 
reset risk portfolios from the user which are sent to the switch mechanism 35 at the 
central processing center 12. The relative position information generated by the 
switch mechanism 35 is returned to Ae switch module 80 which presents the 
position information to the user via the market interface module 74. The auction 

20 module 81 is configured to receive multiple or batch orders on a single instrument 
at different price levels, and in case of a switch auction, to receive a interest rate 
reset risk portfolio from the user. The inputted orders or portfolio is sent to the 
auction server 34 at the central processing center 12 where the auction or switch 
auction, respectively, is performed. The resulting matches are returned to the 

25 auction module 81 which presents the results to the user via the market interface 
module 74. 

The trader workstations 20 includes a processor 82 that communicates with 
other elements within the trader via a system interface 84. An input device 86, for 
example, a keyboard or pointing device, is used to input data from the user, and a 
30 screen display device 88, for example, a monitor is used to output data to the user. 
A memory 90 within the trader workstations 20 includes the Internet browser 
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program 72 (and thus, the trader module 70) and a conventional operating system 
94 which communicates with the Internet browser program 72 and enables 
execution of the Intemet browser program 72 (and thus, the trader module 70) by 
processor 82. It is noted, however, that the trader module is preferably 
5 implemented as a Java-based program that is downloaded into memory 90 for the 
execution during a single session, and the trader workstations 20 will not 
persistently store the trader module 70. Further, as a Java-based program, the 
trader module 70 will be executed on a JVM 73 w^ch is a component of the 
Intemet browser program 72. 

10 An external communication link 96 is provided to interface the trader 

workstations 20 with other computer systems or computer-based devices such as 
respective business unit servers 18. Lastly, a hard disk 98 may be provided as a 
persistent memory device, as well known in the industry. It is noted that the trader 
workstation 20 may comprise a desktop computer system as previously mentioned, 

15 or alternatively, the trader workstation 20 may comprise a portable computing 
device such as a notebook computer, handheld PC, personal digital assistant (PDA) 
or any other suitable device capable of running an Intemet browser program and 
creating a commimication link for interfacing with a network. 

Therefore, a user of the system 10 is not necessarily tied to a specific 

20 hardwired terminal, but has a virtual terminal that goes with the user wherever 
the user has access to a Java capable browser and Intemet access. The trader 
module 70 may be implemented as an independent program capable of establishing 
a communication link to the central processing center 12 via the Internet, a local 
area network (LAN), or a wide area network (WAN). Thus, the user can even 

25 have access to the system 10 via direct modem dial-in to the central processing 
center 12 over the public switched telephone network (PSTN) or Intemet. 

With reference now to FIG. 4, illustrated is an embodiment of a business 
unit server 18 which includes a proxy agent 110 in accordance with the present 
invention. The proxy agent 110 may perform numerous functions including 

30 decoding and encoding encrypted messages sent and received over networks 16. 
The proxy agent 110 manages traffic to and from the trader workstations 20, and 
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may provide other features sudi as document caching and network access control. 
, The proxy agent 110 ntuiy iminove perfonnance by storing and supplying 
frequently requested data to the trader workstations 20, or by filtering and/or 
discarding information from the networks 16. Preferably » proxy agent 110 resides 
5 on a business unit server 18 which is pait of the respective client sites 14 internal 
data networks. However, the system 10 of the present invention may be 
implemented without business unit servers 18, whereby the functionality of the 
proxy agent 110 may be incorporated into the trader module 70 of die respective 
trader workstation 20; such frinctionality including decoding and encoding 

10 encrypted messages, and network management 

The business unit server 18 includes a processor 112 that communicates 
with the other elements within the business unit server 18 via a system interface 
114. An input device 1 16, for example, a keyboard or pointing device, is used to 
input data from a user, and a screen display device 118, for example, a monitor, is 

15 used to output data to the user. A memory 120 within the business unit server 18 
includes the proxy agent 110 and a conventional operating systems 122 which 
communicates with the proxy agent 110 and enables execution of the proxy agent 
110 by processor 112. An external communication link 124 is provided to 
inter&ce the business unit server 18 with other computer systems or 

20 computer/based machines such as networks 16 and trader woricstations 20. Lastly, 
a hard disk 126 may be provided as a persistence memory device, as is well known 
in the industry. Particularly, the hard disk 126 may include trader data profiles 128 
for each of the different trader woricstations 20 associated with the business unit 
server 18. Alternatively, the trader data may be stored at the central processmg 

25 center 12 so that the trader does not need to re-build his/her screens each time 
he/she longs onto the system 10. 

Thus, each trader workstations 20 at a client site 14 is able to access the 
system 10 through the Internet browser program 72 operating on the user*s 
desktop computer. In order to access the system 10, the user may r\m Java-based 

30 applets on the desktop computer in the Intemet browser program 72 which may 
be up-loaded to the desktop computer system by one of three means: 1) accessing 
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tbem fipom the bard disk of the desktop conqnuer 2) downloading them across the 
network from a server on the internal data iKtwork of the client site, or 3) by 
downloading them directly from the central processing center. Once the applets 
are loaded and running in the desktop computer of the user, the user is then able 

S to access the system 10 and interact with other trader workstations 20 and engage 
in trading activities. In addition to traders at the client sites, a preferred 
embodiment of the present invention also enables non-trader users at the client 
sites 14, such as credit officers and other interested/relevant staff, to have access 
to the invention in the same manner as the users in order to monitor the trading 

10 activities, perform credit control or any other functions. 

in. Svstem Features 

The following are features of the present invention which provide 
particular functionalities and utilities. These features include interfaces such as a 

15 command center interface, a market entry interface, a market details interface, an 
outstanding order interface, an historical order interface, and fimctions such as 
symbology, credit preference checking, term negotiation, automatic notification, 
interest rate reset risk switches, and order auction. 

When beginning a session on the system 10, a user at a trader workstation 

20 20 launches the Internet browser program 72 and goes tc a particular address that 
connects the trader workstation 20 to the cemrai processiiig center 12. This is 
preferably achieved by typing a known URL (Universal Resource Locator) in an 
address field of the Internet browser program 72. At the URL entered, the user 
will be presented with a log-on screen which preferably requues the user to input 

25 a user name and password for identification, verification and security reasons. 
After the user logs on, the user will download (preferably from proxy agent 110) 
the Java applets which will run locally on the desktop computer comprising the 
trader workstation 20. Alternatively, the user may launch a local or network 
application that runs locally or on an attached server. The application will enable 

30 a connection to system 10 over network 16, much the same as numerous dial-up 
services such as AOL. hi addition, other information such as user defined 
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preferem^ which are based on the trader's profile will be downloaded to the 
trader workstation 20. This may include information on what the user is allowed 
to trade, what markets the user is interested in monitoring, and other user 
specific information that was previously been defined by the user or another 

5 individual such a credit officer or the like. 

After the user has successfully logged on and the requisite Java s^plets 
have been downloaded and are running on the JVM 73, the user is presented with 
a command center interface 130, as illustrated in FIG. 5, via the screen display 
device 88 (FIG. 3). The command center interface 130 is the front end of the 

10 user interface which provides access to all other features of the present invention, 
as described below. In an embodiment of the command center interface 130, the 
command center interface 130 is a pop-up window rendered on the screen display 
device 88. Note, however, when the command center interface is rxmning, the 
user may be able to iconize (i.e. , minimize) the Internet browser program 72 

IS window, as may be desirable when the user no longer needs to view the Internet 
browser program 72. 

From the command center interface 130, a user can access the features of 
the system 10 which enable the user to monitor and control then: trading in the 
system 10. Specifically, from ^ command center interface 130 the user can 

20 access the following areas of functionality as menu options on the tool bar 132: a 
market entry interface (described below with reference to HG. 12), a credit 
settings interface (described below with reference to FIG. 10), a switch engine 
interface (described below with reference to FIG. 22), auction interface (See 
FIG. 13), tools, a user preference interface (described below with reference to 

25 FIGs. 6A and 6B), an historical order blotter interface (described below with 
reference to FIG. 17), an outstanding order blotter interface (described below 
with reference to FIG. 16), links to external applications such as MarketSheet™ (a 
trademark of TIBCO. Inc.) (referred to herein as the quote screen and graph 
screen for illustrative purposes), a logout interface (provides secure exit from the 

30 system 10), and a help interface where detailed on-line help is provided. The 
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menu options that appear in the tool bar 132 are preferably customizable to a 
user, and those described are merely illustrative. 

In addition, the command center interface 130 provides a message display 
window 134 for displaying real-time messages. These messages include system 

5 information, market information, requests-for-prices (RFPs), requests-for-switch 
(RFS) or online chat sessions with the users of the system 10. Below the 
message display window 134, the command center interface 130 displays the 
user's name 136, the user's default currency 138, the user's business unit 140, 
and other relevant information. The background color of the message display 

10 window preferably changes if the coimection to the central processing center 12 
is lost for any reason. 

A user preferences interface 148, which is accessible fiom the command 
center interface 130 via the tool bar 132, provides a user with user preference 
features, such as those illustrated in FIGs. 6A and 6B. In FIG. 6A, a Derv 

15 Filters tab enables a user to set request-for-price (RFP) filters for viewing 
different derivative instruments based on the type (i.e., class) of derivative 
instruments and the currency. The user may also select the manner of 
presentation (Le. , highlighted or not). From the Derv Filters tab, the user is able 
to add and remove the derivative instnraients from the user's viewing list, that is, 

20 the list of instrument that will appear on the message display window 134 of the 
command center interface 130. In FIG. 6B, an Environment tab enables a user to 
select viewing options to change the appearance of the display. In regard to the 
color coding display option, it is noted that the user can select not to have order 
information color coded by selecting color blind user. In such a case, other 

2S means of notation are utilized such as maricings or symbols, as may be desirable 
if the user is color blind or using a monochrome screen display device 88. User 
defaults for Credit Group, lostrumeni Class and SWF Currency may also be 
selected via the environment tab. 

At this point, it is worth noting several functionalities that are integral to 

30 the operation of the present invention. In particular, it was recognized that in 
order to achieve an electronic trading system for a wide range of financial 
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contracts, a sohition had to be developed to solve two very critical problems: (1) 
how to identify financial contracts, and (2) how to allow institutions to describe 
their credit preferences or relationships for these instruments. As sohitions to 
these problems, the present invention provides the symbology and credit 

S preference features described below. 

The symbology of the present invention was developed because, unlike 
foreign currency trading, where the financial instruments are single, verbally 
explaining all the terms and conditions of a derivative transactions can be a 
laboriously coiiq)lex process which can take a relatively long period of time to 

10 explain. Furthermore, most derivative transactions are specifically customized to 
fit a particular need. With derivatives, as compared to stocks, bonds or other 
financial instruments, there are typically many more parameters, such as the 
maturity, fixed interest rate, floating interest rate, currency, floating rate index, 
and calculation rates, which are inq)ortant and are preferably defined. This 

15 conQ)lexity has allegedly been one of major inhibitors to the development and 
inq>lementation of an efficient inter-dealer electronic trading system for over-the- 
counter (OTC) derivatives. 

The symbology will, among other things, ensure that the symbols are 
intuitive to the trading community, allow new symbols to be system generated 

20 when new instruments are introduced, and enable detailed confirmations to be 
prepared. These goals are generally accon^lished by systematically dividing the 
parameters, terms, and conditions defining these derivatives instruments into a 
four-part subject code. This four-part subject code enables the users to reference 
these instruments via a form known as subject-based addressing. The four-part 

25 subject code is divided as follows: SOURCE.CLASS.SYMBOL.CURRENCY. 
Each field of the four-part subject code is defined below. 

The source field of the symbology identifies the source of the 
information. In most cases, this will be the code DNI (/.e., Derivatives Net, 
Inc.), the assignee of the present invention. If the symbol is used within the 

30 system 10, then the source field of the symbology will be assumed to be DNI, 
and will be omitted. If the symbol is used in a larger context, then the source 
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will be identified. If, for example trade data were to be distributed and accessed 
via a third-party data distribution system such as the type operated by Reuters, 
Inc., then the source field of the subject code would be used. 

The class field identifies die principal product class into which the 
5 financial instniment falls. The class parameter is designed to group financial 
contracts together which share similar attributes. For purposes of the present 
disclosure, eleven classes of instruments, each widi distinct characteristics 
covering forward rate agreements, interest rate swaps, interest rate basis swaps, 
interest rate options, foreign exchange and switches, wiU be covered. It is noted 
10 that a switch is the simultaneous purchase and sale of two insmmients within the 
same class. The following is a listing of the eleven classes and the associated 
abbreviation for each: 

FRA - forward rate agreement 
SWP - interest rate swap 
15 CAP - interest rate option (cap or floor) 

SOP - interest rate option ( swaption) 
IBS - interest rate basis sws^ ( floating vs. floating swap) 
SPT - foreign exchange spot 
FWD - foreign exchange outright forward 
20 FXS - foreign exchange sws^ 

SWF - FRA switch 

SWT - switch any other pair of instruments in the same class 
CBS - currency basis swap 

25 The symbol field is the principal code used to define each instnunent. 

The symbol field is the most explicit field of the subject code. This component 
of the naming convention enables the underlying strucuue of the derivative 
instrument to be defined. A swaplt description (e.g. , lyrswap) could be used, 
but this does not allow new derivative instruments to be easily added. The 

30 legend below defines the parameters for defining each of the different instruments 
or classes. The symbol relies on the definitions of die underlying parameters. 
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\t^cb will allow further break down or defiiiition. For example, FLOPT is a 
two letter code vtdiich describes the variable rate index to be used, and will 
include: the designated maturity, index name, source, non-business day 
convention and calculation descrq>tioa. The symbols of the present onbodiment 
5 are as follows: 

FRA: [START. END, OVER. FLOPT] 
SWP: [START. END. OVER. FXDBASIS, FLOPT. SPECIAL 
RULE] 

10 CAP: [START, END, OVER, FLOPT. TYPE. STRIKE] 

SOP: [START. OVER. UNDERLYING SWAP. SOPTYPE, 
STRIKE, OPTTYPE] 

IBS: [START, END, OVER, INDEXl, INDEX2, ARREAR] 

SPT: (CCYl(terms), CCY2 (base)] 
15 FWD: [CCYKterais). CCY2 (base), START, END. OVER] 

FXS: [CCYKtenns), CCY2 (base), START, END. OVER] 

SWF: [FLOPT, DAYl, DAY2] 

SWT: [ASSETl, ASSET 2, CLASS] 

CBS: (START, END, OVER. INDEXl/CCYl. INDEX2/CCY21 

20 

The symbol fields set forth above include the following parameters: 

START: The START parameter is the month the contract commences 
ofEset from value date, i.e., 1,2,3,. ..13.. ..,360. The default setting for the 
25 START is (0) which represents that a contract startiog with the current 

month. Also, see OVER below. 

END: The END parameter is the fmal maturity from value date in months 
adjusted for the OVER, and represents the term, i.e., 1.2.3. ...13.. ...360. 
30 If the value date is 28th of November, then a contract defmed as (1 ,4 over 
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the 12th] translates into a deal starting on the 12th of January and 
maturing on 12th of April. 

OVER: The OVER parameter represents a specific date in the appropriate 
5 nionth. For example, if today is the 3rd December (value date is the 5th 

of December), then a 1*4 over die 12th would start the I2th of January, 
the first date over one month but less than two months beyond the spot 
date. This allows a contract to be defined with any start date between 
days 1-31. Note that this represents the actual date and not the number of 

10 days forward. The default setting for the OVER is (0), which represents 

spot starting. Two other parameters are allowable: (I) which represents 
IMM (International Monetary Exchange) rolls (the system 10 covers the 
different IMM conventions defined by the currency market, that is, the 
third Wednesday or second Thursday) and (E) which represents rolls over 

15 the month-end. 

FXD BASIS.* The FXD BASIS parameter is a two-part code covering the 
frequency and the basis of the fixed coupons. Examples are FREQ: 
M=Monthly, Q^Quarterly, S= Semi-annually, A^Aimually, Z = Zero 
20 Coupon plus BASIS F= A/365 Fixed, B== 30/360, M= A/360, 1= A/365 

ISDA, etc. For instance, SM is semi-annual A/360 or semi-money]. 

FLOPT." The FLOPT parameter is a two-part code covering the frequency 
and the index type of the floating coupons, and represents the floating rate 

25 option as defined by ISDA. The FLOPT parameter covers frequency, 

basis and source. Although each currency may have a default, most 
indices will be available. FLOPT exan^Jles are L=Libor (TELERATE 
3740/50), P=Pibor (TELERATE 20071). T=Tibor, C=CDOR, B = 
AUS Bills (REUTERS BBSW), FF= Fed Funds (HI5), TB= T-bills 

30 (H15), PR= Prime (H15). CP= 30 day Commercial Paper, BE= BELO, 
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S= STIBOR. TA= TAM, A=AroOR. D=aBOR (REUTERS DKNK). 
RL = Libor from Roiters UBO, and IL= Libor from Reuters ISDA. 

CAPTYPE; The CAPTYPE parameter iittludes definitions for cap (C) 
5 and the floor (F). Thus, in a preferred embodiment, the following code is 

utilized: C= Cap. F= Floor. 

SOPTYPE. The SOPTYPE parameter includes definiiions for payers (P) 
and receivers (R). Thus, in a preferred embodiment, the foUowmg code 
10 is utilized: P= Payers, R== Receivers. X=CalI, Y=Put. 

OPTYPE; The OPTYPE parameter is the option type: (E)uropean, 
(A)merican or (M)uitiple European. 

IS STRIKE: The STRIKE parameter indicates the cap or swaption's exercise 

rate or price set on the option. Any strike defined in the symbol as ATM 
(at-the-money) will be shown as such in this parameter. In such a case, 
the percentage or strike will be agreed through the term negotiated 
process discussed below. 

20 

SPECIAL RULE: The SPECIAL RULE parameter is designed for 
currencies such as USD and CAD which are in particular markets that use 
few special conventions for trading. For exanq>le, semi-bond for spread 
trades and annual money for out-right swaps are widely used in these 

25 markets. The SPECIAL RULE parameter aUows the system 10 to set 

more than one set of defaults for any currency. This will allow the 
system 10 to know when the exchange of bonds is required following a 
transaction. The follow are the rules for the present embodiment: 
A - Default in all currencies 

30 S - USD spread trades. The default in USD is annual money 

versus 3 month LIBOR. This rule defines semi-bond spread trades 
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where bonds are exchanged in the terms negotiation function 
described below. 

2 - CAD spread trades. The de&ult in CAD is annual money 
(A/365 fixed) versus 3 month CDOR paid semi-annually. This rule 

5 defines semi-annual A/365 fixed versus 3 month CDOR paid semi- 

annually where bonds are exchanged in the terms negotiation 
function described below. 

3 - AUD long trades. The default for AUD is a 
quarterly/quarterly structure. This applies for trades up to and 

10 including three years. In trades over three years, the convention 

switches to a semi/semi structure. This rule supports a semi/semi 
structure. 

4 - AUD spread trades. Its is conventional to trade swaps in the 
AUD market against the bond futures contracts with an agreement 

15 for an exchange for physical. 

5 - GBP spread trades. The default in GBP is annual money 
(A/365 fixed) versus 6 month LIBOR. This rule defines semi- 
annual A/365 fixed versus 6 month LIBOR where bonds are 
exchanged in the terms negotiation function described below. 

20 

ARREAR.' The ARREAR parameter defines when the coupon(s) on a 
swap is both set and paid. Most interest rate swaps set their floating rate 
coupons at the beginning of the period and pay them at the end of a 
coupon period. In an ARREAR swap, however, the coupon is set and 
25 paid at the end of the period. This is commonly referred to as an arrears 

swap. The system 10 allows for this in the form of a basis swap. 

DAYl/2.- The DAYl/2 parameter is the number of calendar days offset 
from today to the start of each FRA in an ERA switch (class SWF). Thus, 
30 the DAY 1/2 parameter represents the setting day or date. 
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CCYl/2; The CCYl/2 parameter is the currency code and is defined by 
the ISO codes for foreign exchange instruments. 

UNDERLYING SWAP: The UNDERLYING SWAP parameter is the full 
S symbol, alais or security ID of the interest rate swap that underlies an 

option. 

INDEXl/2; Basis Swaps are when both sides are a floating rate, and the 
index represents the FLOPT plus the currency code of each index. The 

10 first listed index (INDEXl) is paid by the buyer. Examples include IL- 

USD, 3L-GBP, PR-USD. etc. The second index (INDEX2) is received 
by the buyer. These are substantially identical to the codes used in die 
switch mechanism 35 (FIG. 2). For currency basis swaps, it is assumed 
that an exchange of principals takes place at the start and end on the 

IS contract. 

ASSETl/2; The class SWT is provided to allow for the trading of 
switches in other classes other than FRAs. ASSETI and ASSET2 
represent the symbol, alias or security LD. of each underlying contract. 
20 Note that both should be provided from the same class of contracts. 

SETTLE.' The SETTLE parameter is a flag indicating whether a swaption 
is cash or physical settlement. The de&ult is cash (C). 

25 An example of an order m accordance with the symbology of the present 

mvention is DNI.FRA.1,4.0.3L.USD, where DNI is the source, FRA is the 
class, . 1,4.0,3L is the symbol and USD is the currency. In particular, the 
symbol field defines a 1 by 4 {i.e, , 3 month starting in L month) FRA on a 3 
month LIBOR spot starting. Note that a comma (,) is used in the symbol fields 

30 as a delimiter. Another example of an order in accordance with the symbology 
of the present invention is DNI.SWP.0,60,0,AB,6LA.DEM. where DNI is the 
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source, SWP is the class, 0,60,0,AB,6LA is the symbol and DEM is the 
currency. In particular, the symbol field defines a five year (60 month) annual 
bond (AB) versus a 6 month LIBOR swap. 

Accordingly, the Symbology described above is designed to capture the 
5 parameters or commercial terms of a derivatives instrumem which affect the 
instrument's valuation. The present invention provides a number of default 
values which are assumed at all times. For example, the following is an 
exemplary list of system default values. 

10 ROUNDING: The rates observed on the source page or document will be 

used unless otherwise agreed. Rates should be rounded to 5 decimal 
places after any operation of averaging. 

RESET DATES: This will be defined with reference to payment dates. 
IS The reset dates should be offset by the standard number of days for the 

currency, for exanq)le, two business days for USD. 

BUSINESS CENTERS TO APPLY TO RESET DAYS: The business 
days used to defme the current offset for reset dates is defmed by the 
20 source and not the payments under the transaction. For example, London 

will always be used for LIBOR (the exception is for USD LIBOR which 
uses both London and New York City) and New York City for H.I5 
rates. 

25 INTERPOLATION: Where interpolation is required, a straight-lii^ 

method using the reference rates on either side of the desired date should 
be used. 

CALCULATION PERIODS: First and not last convention. Therefore, the 
30 calculation period includes the fu*st payment date but excludes the next 

payment date. 
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TERMINATION DATE: All termination dates will be subject to 
adjustment if they fall on a non-business day. 

ADJUST CALCULATION PERIOD: The number of days is assumed to 
adjust if the payment days are adjusted for non-business days. 
TRADE DAY: The trade day is defmed relative to the instrument and 
currency by the system 10, and not by the location of either of the parties 
to the transaction. 

NET PAYMENTS: Net payments will be assumed for all transactions 
completed through the system 10. 



CANADIAN DOLLAR SWAPS: The convention is to set quarterly and 
IS pay semi-annually using weighted averaging and conq)ounding at the first 

rate. 



10 



DATES: All dates are listed unadjusted for non-busmess days. 

20 Users may also want to be able to negotiate other parameters which do 

not affect the valuation of the derivative instnmient, but are still very important. 
These parameters are referred to hereinafter as non-conraiercial terms. The 
difference between commercial and non-commercial terms can be vary 
ambiguous, and therefore, some of the terms designated as commercial below 

25 may be designated as iK>n-commercial and become default settings so as to be 
part of the symbology parameter. For purposes of illustrating the present 
invention, non-commercial terms have been given default values which the users 
can change by negotiating new values for these terms between themselves via the 
system 10. However, both counterparties (users) must agree on the new value to 

30 over-ride the system defaults. Table 1 below provides a list of parameters that 
maybe negotiated, that is, the non-commercial terms: 
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PARAMETER 


DESCRIPTION 


SETTING 


Legal 


The fonnat of the legal agreement used 


ISDA, BBA, FX 


Month-end 


Whether coupon payment dates roll on 
month-end dates or not 


YES. NO 


Settle 


For swaptions whether the contract is 
cash or physically settled 


CASH, 
PHYSICAL 


First Setting 


For swaps the first variable rate is 
normally known for spot starting 
instruments. The current setting can 
quickly become off market on days 
where the market moves substantially. 
The system will display the default at 
all time. 


SETTING 
displayed on 
market entry 
interface. 


ATM 


For options, symbols will be set up 
where the strike is defined as at-the- 
money (note: pre-defmed strikes will 
also be available). The actual strike 
will be negotiated immediately 
following the transaction by the two 
parties. 


The system 
forward rate will 
be available 


Spot 


For foreign exchange swaps (class 
FXS only) where the price is 
transacted in the form of points, the 
spot level to be used will be negotiated 
immediately following a transaction. 


The system mid 
spot price will be 
available 


Base 


Switches will be transacted in the form 
of the relative price between the two 
instruments being switched. The base 


The system mid 
price will be 
available 
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rate mayoe negotiatea immeaiately 
lOiiowiiig a transaction. 




Bond 


For USD, CAD and GBP interest rate 


The system will list 




9 wans transacted ac s <!nreAd fhe nnre 


tVtf^ h^nrhmnrk' 
txiv Lyciiwiiinaiii 




and number of bonds will be 


bonds to be used 




negotiated immediately following the 


and will calculate a 




transaction 


default price and 






number according 






tomailcet 






convention. 



TABLE 1 

Because the above symbols that comprise the subject-based addressing 
may be con5)lex, users may occasionally desire a simpler naming convention to 
5 reference the more commonly traded derivative instruments. To £Eicilitate more 
F^id referencing of an instrument by a user, the symbology of the present 
invention provides aliases. An alias is merely an abbreviated version of the 
subject-based address for the more commonly used terms for an instrument. The 
database 66 (FIG. 2) maintains a unique security identifier (such as a muneric 

10 code, e.g., 11 1222) for each symbol which can be used in the system 10. Thus, 
the symbology of the present invention enable traders and other users of the 
system 10 to quickly reference a particular derivative instrument in the system 10 
in three ways: the fiiU symbol, the alias, and the identifier. 

The currency field of the symbology contains the code that defines the 

15 currency of the instrument represented. In a preferred embodiment, the currency 
code is represented by the standard ISO currency codes, i.e., USD, DEM. JPY, 
GBP. FRF. NLG. BEF, AUD. CAD, ITL, ESP, DKK. SEK. EUR. etc. The 
default currency will be set by each user in each user's preferences interface 143 
(see FIG. 6B). This will allow the currency code field of the symbology to be 

20 omitted much of the time. However, foreign exchange trades (FXS) preferably 
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include the currency code. Further, the currency code represents the currency 
which will be indexed in equal amounts for both the spot and forward coiqx)ns. 

The credit preference feature of the present invention provides for the 
bilateral credit status between two entities to be captured, stnictured and used 

S anonymously for the trading of a wide range of financial contracts. In prior art 
systems, credit information was primarily used to deal with settlement risk in 
trading spot foreign currency. In such prior art systems, the credit Ime or limit is 
usually expressed in amounts of currency which equates with the quantity or 
volume of a particular trade. As trades are executed between counterparties, the 

10 amount of the limit is decreased in a corresponding amount to the trade executed 
until there is little or no remaining credit, and then further trading is prevented 
until the trades settle or the credit limit amoimt is re-set. In foreign currency 
trading, the settlement process is completed in only a few days, after which both 
counterparties have exchanged the currencies, and then there is no further credit 

15 risk between them (Le,, the trades have setded). This is vastly different from 
derivatives trading, where the amoum at risk is normally not equal to the 
principal or quantity of the transaction and the obligations under the contract may 
continue into the fumre. Derivative trades can be anything from spot (the normal 
settlement of a foreign exchange contract) to thirty years into the future. 

20 Therefore, die resulting credit exposure (i.e. , the value of a contract at a future 
time) is over the life of a contract of an unknown amount. 

The credit preference feamre of the present invention is configured to 
handle the significant long-term credit problems inherent in over-the-counter 
(OTC) derivatives transactions. These long-term credit problems are fiuther 

25 compounded by the fact that there is no standard method for banks to internally 
monitor and manage their credit risks. Most banks have developed their own, 
often proprietary, methods of monitoring and measuring the credit risk embedded 
in large portfolios of derivatives. Furthermore, banks also have different 
methods for dealing with the many different financial instruments that exist in 

30 every market. 
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The credit preference feature of the present invention addresses these 
problems and provides a viable solution. The credit preference feature of the 
present invention achieves this, at least in part, by introducing a measurement 
unit of credit risk referred to as risk equivalent (RQ) which allows for different 
5 insmmients to be compared on a like basis using a standardized measuring 
methodology, which together with the concepts of contract maturity, credit 
groups, classes, credit preferences, legal entities and business units allow the 
system 10 to offer a solution to the credit risks embedded in bilateral, term 
derivatives contracts. The present invention also provides for the designation of 

10 credit groups. A credit group is a grouping of classes of financial contracts that a 
business unit wishes to be treated in a like manner for credit purposes. In a 
preferred embodiment, three defeult credit groups will be available: 
(1) Derivatives - SWP, fflS, CAP, SOP, FRA, CBS; (2) Switches - SWT, 
SWF; and (3) foreign exchange. Any otiier combination may be set up by the 

15 business unit, as desired. 

Credit preferences are the methods or rules selected by a business unit 
within a credit group for the system 10 to use to screen prices (bids or offers) and 
Q-ades against all other legal entities. In a preferred embodiment, the followmg 
three credit preferences are provided, tiiough it will be appreciated by those of 

20 ordinary skill in the art that other credit preferences may be utilized in 
accordance with the present invention: 

Method 1: Binary (simple yes/no) - This is used where mark-to- 
market (MTM) agreements exist between the counterparties. 
25 MTM are bilateral, collateral agreements which are common and 

reduce the credit risk between two parties to ahnost zero by the 
posting of collateral against the value of a portfolio of derivatives 
covered by a singie ISDA (International Swap and Derivatives 
Association) master agreement. 

30 
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Method 2: Line Binary - takes into account the maturity (quoted in 
montbs from trade date) of the financial contract. 

Method 3: Complex - This is based on the RQ of each contract 
5 within maturity bands. The system calculates a RQ for each 

instrument in the form of a constant currency unit expressed as a 
percentage. Each business unit has the choice of using the system 
generated RQ unit or to provide their own. 

10 In the binary method, a business unit makes a yes or no determination as 

to whether or not they will deal with a particular counterparty for a particular 
credit group. In this credit preference, the decision is binary; there is no 
maximum maturity limit {Le, , time limit) or quantity limit (i.e. , amount) in the 
binary method. The binary method is the broadest of the three credit preference 

IS definitions provided for herein. Typically, the binary method will be used to 
refuse credit, where MTM agreements exist or where the credit exposure is small 
(for example, in switches). 

In the line binary method, it is assumed that the business unit will deal 
with a particular counteq)arty for a particular credit group. However, the line 

20 binary method adds a further restriction of a maximum maturity of any contract 
tradable. The added restriction is preferably expressed by the number of months 
into the future. The binary method is panicularly well suited for used by 
institutions that are not yet using RQ units, but which desire a method to limit 
potential exposure to longer dated contracts (for example, a temporary step). 

25 The complex method allows each business unit to exactly stipulate the 

amount of new risk that they are prepared to enter into with any other legal entity 
for each credit group by maturity band. The complex method enables a business 
unit to speciiy not only a particular maturity, but also a particular quantity or 
amount based on a measure of RQ. Further, the complex method enables the 

30 business imit to specify this for more than one period in time. For example, a 
business unit can specify that for Bank A, they will do up to $100 million out for 
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5 years, and then only SSO million from thereafter out to 10 years, and nothing 
thereafter. 

Risk is generally defmed herein as the degree of micenainty of future net 
returns. Credit risk is further defined as an estimate of the potential loss due to 
S the inability of a counterparty to meet its obligations. Thus, while the risk in a 
particular transaction depends not only on the changes in market rates and credit 
standing of the counterparty to the transaction, the credit risk or exposure is the 
nominal amount that can be lost when a counterparty defaults on its obligation. 
As previously mentioned, the credit risk in a derivatives transaction is relatively 

10 complex. For instance, though derivative contracts come in many forms, the 
majority have a fair credit value of zero at the time the transaction is initially 
entered into. That is, no funds are transferred between the parties at the time the 
contract is created. Rather, the contract places an obligation on both over the 
term of the contract. Further, both parties are entering into a contract which 

IS requires them to accept a certain amount of risk. The RQ is a unit of credit risk 
which allows all contracts to be compared on a like basis, at virtually any point in 
time. The RQ is the credit exposure in terms of a percentage of the principal. 

The calculation of RQ is based on the potential exposure averaged over a 
series of time points, weighed by an appropriate discount factor. There are 

20 several methods of calculating the exposure of a transaction, though the RQ is 
calculated herein using an option pricing approach, as described below. 

For a certain party, a transaction can be viewed as two opposite cash 
flows. Inflows are assets, denoted by A(t), and outflows are liabilities, denoted 
by L(t). Therefore, the current exposure may be expressed as follows: 

25 E(t)=max(A(t)-L(t),0) 

This formula is similar to the mtrinsic value of a call option. The key 
difference is that both A(t) and L(t) can be random. Thus, following the same 
structure by the Black-Scholes, then: 

30 
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EE{t) = A^d,)'L(tmd2), 
where 

where a(t) is the daily volatility (m percent) that takes into account that both Aft) 
and L(t) are random. The maximum exposure estimate is based on the following 
5 equation: 



MB(0 = ^(0-^(0 + ^(0 



l.«<r(/)V7(0-^f(/) 



-1 



Thus, the RQ can be expressed as: 



10 



where 



?tinctpal 



^££(0 = i;fl)(/)E[E(t)] 



where 



IS where S(t) is the discount foctor at future time t. 

For FRA's, the following equations apply: 
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Aft) = *discomtFactoriUs)*x + ( 1 -^flocumgCoupon) "^discoumfactor 

iUe) 
where 

floatCoupon=l*(e-s)/floatBasis*floatRate, and 
5 L(t) = 1 *discountFactor(t,5)*x+ (1 '^fixCoupon)*discountfactor(t,e) 

where 

fixCoupon = 1 *(e-s)/fixBasis*fixRate, 
for t<B, x=l, and 
for t> =s, x=0. 

10 Then we can apply the above formula for RQ to get die expected exposure 

at time t. By choosing the time partition tO,tl,t2...., tn and calculate the expected 
exposure at each point and use the formulae of RQ, the RQ of this FRA can be 
calculated. 

For SWAP'S, the following equations apply for any time (tj<t< = ti+,): 

n 

A{t) - ^floatmgPoupoHji)*discountFactoi{tJj) + \*discountFactor{tJ„), and 

n 

W) = X fix^dCoiq)on{tj) ♦ discomtFactOf{t,tj) + 1 ♦ discountFacto?(ijX 

15 

vfhm floatingCoiq>on{tj) is the floating coupon at time t^» and fixedCouponiij) is 
the fixed coupon at time t,. Then apply the formulae of option pricing approach, 
we can get the expected exposure at time t, by averaging the expected exposure 
with the discount factor, the RQ can be calculated. 

20 At this point it may be worthwhile to distinguish the credit preference 

feature of the present invention from odier known systems. The credit 
preference of the present invention does much more than merely monitor the 
amount transacted between two counterparties and then reduce the amount 
available accordingly. The prescreenmg performed by the credit preference of 

25 the present invention is used to prescreen possible trades based on each 

counterparty's credit preferences. The present invention does not control a user 
trading and does not directly limit the user's future trading based upon the user's 
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past trading. In £act, it is quite possible that a new transaction may reduce the 
exposure between two legal entities. A user's business unit is responsible for 
monitoring the credit exposure of the business unit with respect to all legal entity 
counterparties, and for adjusting the credit preferences in the system 10 
5 accordingly. This is a significant difference from prior art systems that 

automatically decrease the amount available to trade with respective counterparty 
as transactions are executed. The credit preference of the present invention 
represents an improvement over such systems because the balance of risk is based 
on the total portfolio between the two parties and not merely the new 

10 transactions, and the balance of risk will be affected by market movements, deals 
executed outside the system 10, and internal changes to the ratings. 

Credit decisions for OTC derivatives are considered different from many 
other financial instruments. In general, a credit decision for an OTC derivative 
is a function of, among other things, the conq)osition of the user's current 

IS derivatives portfolio, the current level or prices of the financial markets, new 
financial transactions, and the rating or level of credit worthiness of each legal 
entity. Therefore, more sophisticated means such as the credit preference 
prescreening of the present invention is needed to adequately measure and 
manage credit e>qx)sure in the OTC derivatives market, as well as with other 

20 £inaiK:ial maiicets. 

The present invention enables the user to set desired credit preferences for 
each legal entity via the credit preference iraerfece 170, as illustrated in FIG. 7. 
A user can navigate to the credit preference interface 170 by selecting the credit 
settings button in the tool bar 132 of the command center interface 130 (FIG. S). 

25 The credit preference interface 170 enables the users to view and/or update credit 
preference settings in a clear, simple, comprehensive and intuitive manner. The 
credit preference interface 170 may be used to view or input/amend the business 
unit's credit preferences. The credit preference settings are preferably only 
viewable by users within a business unit, and amendable by users with the correct 

30 permissions, both of which may be designated by the financial institution or the 
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business unit. A business unit may also select to inherit credit preferences from 
another business unit within its £amily hierarchy. 

In a preferred embodiment, the credit preference interface 170 includes a 
display window 172 that displays various information including an a^habetical 

5 listing of all other legal entities (/.£., financial institutions) that have access to the 
system 10. Each legal entity can be expanded via an e7q)and button 174 to list 
the settings for all the credit groups that the user has selected to trade within that 
legal entity, as shown for the Merrill Lynch entry. For those legal entities that 
are not expanded in window 172, the settings displayed are for a designated 

10 default credit group 176. The user can modify the displayed credit groups by 
selecting the Modify Credit Groups button 178 which launches the modify credit 
group interface 180, as illustrated in FIGs. 8A and 8B. The modify credit group 
interface 180 enables the user to customize his/her class groups by providing 
functionality to perform such operations as adding and removing instruments 

IS from a class group, as illustrated in FIG. 8A. For instance, for a selected credit 
group 182y a listl83 of instruments in that credit group is provided. Unassigned 
instruments can be added and member instmments can be removed. Further, 
credit groups 182 can be added and deleted via buttons 182» 185, respectively. 
In FIG. 8B, each credit group 182 may have bands of maturity 186 defined (/.e., 

20 added or deleted). Each class group preferably includes instruments that are 
closely related because the instruments in each class group are given the same 
credit preference setting, and therefore, the credit preference setting process may 
be sinq)lified. 

Referring back to the credit preference interfiace 170 of FIG. 7, a 
25 preference setting column 187 provides the credit preference setting designated 
for the corresponding legal entity 183. The credit preference settings for any 
legal entity can be modified or selected via a drop-down dialog box 188. From 
die drop-down dialog box 188, the user can select from a list of predefined credit 
preference option. For a new line binary, the user is prony)ted with a new line 
30 binary interface 189 in which the user can enter a maturity. For complex, the 



-49- 

SUBSimiTE SHEET (RULE 26) 



wo 99/19821 



PCT/US98/21518 



user is prompted with a complex prefereiM:e imerface 190 (FIG. 9B) in which the 
user can enter die exposure for each maturity band. 

With reference back to HG. 7, the conq)iex credit preference settings and 
die RQ may be provided for each instruments designated as such by selecting an 

S appropriate legal entity and then selecting the Complex Bands button 194. 
If the user does not set a particular preference for a particular 
counterparty, then the credit preference will be assumed to be a simple binary 
(no). If after initially setting these preferences a new counterparty is added to the 
system, the preference for the new counterparty will be binary (no) for all users 

10 until they have specifically set a credit preference for the new counterparty. 

The level column 196 displays the business unit's designation for each 
legal entity as to the levels A, B or C. The level set for each legal entity may be 
provided by the system 10 via various interfaces such as a market detail interface 
(described below with reference to FIG. 15) to provide the trader with 

15 information with regard to the creditworthiness of the counterparty. Thus, a 
business unit may assign one of the levels A, B or C against each legal entity. 
This is essentially a quick reference of credit worthiness for the user. 

The colunms 198 labeled S&P and Moody are industry credit ratings that 
are integrated into the credit preference interfece 170. The industry credit 

20 ratings may be downloaded on a subscrq>tion basis via external communication 
interfiace link interface 62 (FIG. 2). Lastly, the last modified column and the 
modified by column identify the time and person that last modified that credit 
setting. As mentioned before, access to modify any of the credit preferences 
should be limited to a finance officer or credit officer of the legal entity. 

25 It should be noted that the credit preference settings may be transferred 

via electron file transfer or iKq)Utted manually on-line at anytime, and as often as 
the user desires. Further, updates inay be made for all credit groups and legal 
entities, or alternatively, updates can be just for individual settings. 

In addition, the credit preferences interface 172 includes a BU Info button 

30 202 which, if selected, brings up a business unit data interface 204, as illustrated 
in FIG. 10. The business unit data interface 204 enables the users to view 
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telpfid imenial infonnation about Other legal en^ The respective business 
units define what information is included in the business unit data interface. For 
example, the business unit data mterfiace 204 of FIG. 10 provides the internal 
facility number, telq)hone number, internal reference number, internal net 
S MTM, internal gross MTM, and internal number deals of a business unit. 
Alternatively, a business unit may include a contact name or other business unit 
specific data. 

Accordingly, the credit preference logic of the present invention can be 
illustrated graphically as shown in FIG. 1 1 . For purposes of FIG. 1 1, it is 

10 assumed that business unit (i) belongs to legal entity (i) where i= 1 , 2, and 3, and 
business unit (j) belongs to LE (j) where j= 1, 2, and 3. Accordingly, FIG. 11 
illustrates a portion of the credit data which is stored by the system 10 in order to 
inq)lement the credit preference feature of the present invention. Each column 
represents the credit preference (/.e., binary, line binary, or complex) which is 

15 stored anonymously for each business unit against each legal entity across all 
credit groups. The vertical and horizontal bars 210 represent the information 
which business imit (3) requires to determine the credit preference status of an 
order. The information in columns 210 provides the credit preferences which 
business unit (3) has set against all other legal entity, and row 211 provides the 

20 credit preferences which all other business unit s have set against business unit 
(3)'s legal entity, that is, legal entity (3). The depth 216 of the graph is divided 
into the different credit groups such as switch, derivative, and foreign exchange. 

The triai^les 212, 214 mark the cells that include the information which 
is used by business unit (3) to encode a specific order from business imit (5) of 

25 legal entity (S) with credit status information for presentation to the user via one 
or more of the interfaces described herein. In a preferred embodiment, the credit 
preference feature of the present invention color codes the credit preference 
status of each order from the perspective of the viewing business unit. 
Alternatively, another method of encoding the credit preference status of an order 
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may include adding a character notation such as an asterisk or star to an order, as 
may be desired if die user is color blind. 

Each order is color coded according to the credit preferences marked by 
the triangle 212, which corresponds to what the order placer's business unit has 

S set against business unit (3)'s legal entity, and the triangle 214, which 
corresponds to what business unit (3) has set against the order placer's legal 
entity. The order is evaluated according to the credit preference defmed in the 
cells marked by the triangles 212, 214, and the results can be displayed to the 
user via the color coding scheme set forth below where true means that the order 

10 passes the credit prefereiK^e of the setting party and false means that the order 
does not pass the credit preference of the setting party: 

Triangle 212 Triangle 214 Color 

False False RED 

15 False True YELLOW 

True False RED 

True True GREEN 

Thus, each order is color coded to communicate to the user the tradability 
20 of the bids and offers in the maricet based on the preferences of both users. The 
color coding methodology described herein is used in both the market entry 
interfiEu:e (described below with reference to FIG. 12) and the market detail 
interface (described below with reference to FIG. IS). For the present 
embodiment of the invention, the foUowing meanings are associated with the 
25 cited colors: 



GREEN: The price passes the credit preferences of both parties, 
and the couruerparties are free to trade. Any trade that is shown 
in green can be freely traded by the trader, and credit approval is 
30 assumed to be in place. 
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YELLOW: The price posted is free to trade by the viewer, but the 
poster of die price has excluded the viewer from his/her credit 
preferences. If the price is colored yellow, a deal may be allowed 
provided that the party who placed die passive order allows mutual 
5 puts, and the credit over-ride process which is described below is 

conQ)l^ed. The viewer can attenqit to trade by sending a imssage 
(thereby initiating the credit over-ride process) to die poster of the 
price which discloses the name and/or identity of die viewer, along 
wiUi a mutual put maturity entered by die viewer. The poster then 

10 has die opportunity to accept, accq)t subject to credit (in either 

case, the poster may also reduce the maturity of the mutual put), 
or decline. The poster's name will not be released to the viewer 
until a trade is executed. The posted price will remain available to 
all other traders on the system 10 until a trade is con:q)leted. If the 

15 order trades to another viewer, dien the credit over-ride process 

will be terminated. 

RED: The price posted is excluded by die viewer's own 
preferences even diough tb& poster is (may be) clear to trade. In 
20 this situation, the viewer is not free to trade since it is the viewer's 

own credit preference that the viewer set which is preventing the 
trade. 



BLUE: The price is the viewer's own order. 

WHITE: Only used in die market entry interface 250 (FIG. 12) to 
display prices where ttierc are multiple orders at die best price 
wifli differing codes. Thus, die viewer is notified to view the 
market details interfiace for more information. 



-53- 

SUBSTUUTE SHEET (RULE 26) 



wo 99/19821 PCT/US98/21518 

In Ae over-ride process mentioned above, if the viewer sees a price coded 
yellow that he/she wishes to trade, then the viewer may activate the over-ride 
process. The over-ride process begms by prompting the posting party with a 
request for an order quantity. The message sent to the poster essentially states 

S that the viewer, which is identified by name in the message, wishes to trade a 
stated quantity and that the receiving party has a stated period of time to respond, 
for instance, 15 seconds. The viewer will then see a copy of his/her message and 
a clock which displays the countdown of die stated time to the poster. The poster 
receives the message and can decline or accept. If the poster declines, then the 

10 viewer is informed accordingly. If the poster accepts, tten the poster has the 
option to add a mutual put maturity and request a small price adjustment, which 
will be stated in a specified number of months. The viewer cannot back out of the 
trade while the clock is running (unless a price adjustment is requested). 
Funher, at no time is the poster in a trade until all steps are complete. 

IS The process by which passive orders are color coded is described at this 

point. Regardless of the credit preference type, the trader woricstation 20 
generates a maximum maturity value that determines how an order will be color 
coded. The m?yi"iiini maturity value is in the form of an integer n digits in 
length, with the right-most two digits r^resenting days, and the left (n-2) digits 

20 representing months. Therefore 12000 represents 10 years, 3600 represents 36 
months, and 114 represents 1 month, 14 days. The meUiod by which credit 
preferences are converted to a maximum maturity value is represented by Table 2 
below. 

25 



Preference 


Maximum Maturity 


Type 




Binary No 


-2^\ the smallest possible integer value 
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Binary Yes 


2*^-1, the largest possible integer value 


Line Binary 


The maxinmm maturity associated with the preference 
(e,g,, LiiK Binary/12 has a max manirity of 1200) 


Complex 


The maturity of the highest band with an exposure 
anusunt greater than zero. 

(e,g,, The following coiiq}lex preferrace would have a 
max maturity of 6000) 




Mat Band Exposure 
100 10,000,000 
600 5,000,000 
1200 3,000,000 
3600 1,000,000 
6000 500,000 
12000 0 



TABLE 2 



Every instrument in the system 10 possesses a maximum maturity value. 
5 To determine whether a particular order can be traded, the maximum maturity 
for the order's instrument is compared to the maximum maturity of the credit 
preference. If the instrument's maximum maturity is greater than that of the 
credit preference, then the order may be traded, otherwise it cannot be traded. 
Note that the maximum mamrity assigned to a Btnary-No preference will 
10 be lower than that of any instrument, effectively making all instruments 

untradeable. Likewise, the maximum mamrity of a Binary-Yes preference will 
exceed that of any instrument. 

In order to determine the appropriate color code, the trade workstation 20 
maintains two lists for each instrument class. One list includes the credit 
15 preferences that the viewer has set against all other legal entities for that 
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10 



instrument class. This list may be referred to as MY_PREFS. The other list 
includes the credit preference that ail odier business units have set against the 
viewing legal entity for that instrument class. This list may be referred to as 
OTHER_PREFS. Each of these lists contains the following data: 

Business Unit ID (Only used for OTHER^PREFS) 
Legal Entity ID (Only used for MY^PREFS) 
Maximum Maturity 

Credit Level (Only used for MY^PREFS) 

Consider, for instance, an order for an arbitrary ERA instrument placed 
by business unit (1) of legal entity (1). When the order is broadcast out to a 
plurality of traders 20 (Le. , viewers), the order will include the following 
information: 

Business unit of trader placing order: business unit (1) 

Legal entity of trader placing order: legal entity (1) 
Maximum Maturity of order: 3600 (for example) 



20 In order to color code the order, the viewing party must extract and utilize 
his/her credit preference against legal entity (1) from the FRA MY_PREFS list, 
and business unit (l)*s preference against him/her from die FRA 
OTHER PREFS list. From the credit preferences extracted, the color of the 
order as it will appear to the trader is as defined in Table 3 below. 

25 



15 
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\fY PREFS 
PRHFERENCE 

max manirity > = 
3600 


OTHER PREFS 
PREFERENCE 

max matunty > = 3600 


Color of Order 


Mse 


raise 


rea 


Mse 


tme 


red 


true 


false 


yellow 


true 


true 


green 



TABLE 3 



Also, note that the MY^PREFS list may contain a credit level (e.g., 
5 which may be associated with the order and presented to the viewer. 

Accoidingly, when the user logs into the system 10, the user populates 
the MY_PREFS and OTHER_PREFS lists for the instrument classes for use by 
the credit preference module 76 (HG. 3). This is achieved by the central 
processing center 12 sending to A trader workstations 20 that is logging-on one 
10 or more messages including the MY__PREFS and OTHER^PREFS lists from the 
database 66 on die hard disk 64 (HG. 2). 

When a user changes a credit preference assigned to a legal entity for a 
particular credit group in a way which causes the maximum maturity of the credit 
preference to change, the user will receive updates to MY_PREFS from the 
15 central processing center 12. Also, any user within the affected legal entity who 
is logged on to system 10 will receive an update to OTHER_PREFS. Changes to 
complex preferences do not require such an update unless the zero band is 
changed (thus modifying the maximum maturity). If the user changes the credit 
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level associated with a legal entity, the user will receive an update to 
MY^PREFS. 

However, these two updates should not be performed at the time the 
changes are made, as doing so could allow a user to determine the legal entity 

5 that placed an order by methodically changing his/her credit preferences against 
each legal entity from a green state to a red state until the order changed color. 
Instead, the required updates will be collected and sent out on an periodic basis. 
Also, to discourage discovery of a counterparty's identity by assigning a unique 
credit level to a single legal entity, each credit level should be assigned to either 

10 no legal entity, or to more than one legal entity. 

From the command center interface 130, a user may enter the market 
entry interface 250, as illustrated in FIG. 12. At the maricet entry interface 250, 
the user can simultaneously monitor numerotis markets and place orders, 
including bids and offers. The market entry interface 250 also allows the trader 

15 to select any instrumenl(s) to be displayed, and multiple market entry interfaces 
250 with various trading functions (e.g., common FRA on one interface, SWAP 
on another interface, and Switches on yet another interfece) may be opened on 
the trader's desktop simultaneously. The market entry interface 250 is designed 
to present the sum of the best bid and ask. and the act of trading by any two 

20 parties by a flashing volume indicator in the top right-hand comer. Thus, the 
market entry interface 250 enables a trader to easily monitor many different 
markets with relative ease and utility. It should be noted that the system 10 does 
not perform auto-matching of orders, but allows the user to maintain control of 
the trading process at all times. The system 10 does this by introducing the 

25 concepts of active and passive orders. A passive order is an order placed in the 
system 10 for a particular instrument, for a particular quantity, at a specific 
price, for a particular time period (see order types below). An active order is 
when a user decides to trade a passive order displayed in the system 10, and is 
usually only required to provide the quantity. Thus, there can be active or 

30 passive bids and offers. 
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The user may customize the market entry inter&ce 250 by adding and 
removing instmments (Le. , mark^) displayed in the instrument display window 
252. The user may add new markets by entering an instrument symbol 
(according to the symbology of the present invention) into instiument identifier 

5 field 254. The user may also want to define groups of instmments which can be 
saved as profiles and viewed together. Profiles allows the user to organize 
multiple markets by like attributes. The profile being viewed is displayed in the 
profile display field 256. The profile display field 256 is a puU down menu that 
lists the other profiles defined by the user. Until die user defines a first profile, 

10 the profile display field 256 is set to default. 

Individual markets displayed in the instnmient display window 252 are 
divided into four columns: instnmient, best bid, best ask, and info. The 
instrument column displays the instrument name O'.e., the symbol, alias or a 
security identifier). The best bid column displays the best bid information, 

IS defined herein as the orders that are at the best price. The best bid mformation 
includes a relatively large central number that displays the least two significant 
digits of the price, a bottom left number that displays all but the least two 
significam digits of the price, a bottom right number that displays any volume or 
quantity currently trading, and a top right number that displays the quantity of 

20 currency units in millions. I>q)ending on the precision desired, a greater or 
lesser number of digits can be displayed as the larger central number. The 
precision of the displayed central numbers is defined for each instrument, and 
may, for example, include 2, 3, 4, or more digits. The best ask column is 
substantially identical in format to the best bid column, but displays the best 

25 asking price rather than the best bid price. The info column provides space for 
data items that the user may select to view, as defined in an info window 258. In 
the present embodiment, three items are defined in the info window 258, and 
thus, the corresponding information for the instrument will be listed in the info 
column. 

30 The system 10 provides users with a symbol construction interface 270, as 

illustrated in FIG. 13, that can be accessed via a Lookup button 272 from the 
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market entry screen 250. The symbol construction interface 270 fiinctions to aid 
the user in selecting instnunent for display in the instrument display window 252. 
From the symbol construction interfoce 270, the user can view available aliases 
in window 273, ejqplode a symbol (i.e., view a list of underlying parameters 

S associated with the symbol, for example, payment date) via the Explode Symbol 
button 274, select symbols to be added to a profile via the Add to Profile button 
276, and construct new symbols or aliases via the Build Symbol button 278. The 
symbol construction interface 270 also provides error checking soch that only 
valid symbols can be selected. An instrument should exist in the database to be 

10 valid, and not all combinations will exist. For additional verification, the symbol 
explode foinction of the Explode Symbol button 274 enables essentially all aspects 
of the instrument to be displayed in detail. Thus, the explode symbol feature 
provides a con^)lete detailed description of the instrument in Symbol window 
280. 

15 The symbol construction interface 270 screen also enables the user to 

search for groups of symbols by at least partiaUy filUiig out the input parameters 
282 located above a Search Options button 284, and then selecting the Search 
Options button 284. The input parameters 282 include various non-commercial 
terms of an instrument that can be negotiated following a transaction. For 

20 instance, as shown in FIG. 13, the input parameters 282 include class of 

instrument, currency, start month, end month, over, FLOFT, and special rules. 
By at least partially filling in these parameters, the user can search for similar 
instruments which are displayed in window 280. 

Referring back to market entry interface of FIG. 12 , it is noted that the 

25 prices displayed in the best bid and best ask columns are eiKxxled with credit 
information using the color scheme described above. As previously mentioned, 
color-blind users can have the color coding scheme replaced by a symbol scheme 
in which different symbols are positioned next to the respective prices to indicate 
the credit status of the order. The symbol scheme may be chosen by the user 

30 under the Environment tab of the preference interface 148 (see HG. 6B). 
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It should also be noted that the inventors of tte present invention are not 
presently aware of any electronic trading system that offers color-based credit 
preference pre-screening such as that disclosed herein. The present invention 
provides color-based credit preference pre-screening because, unlike the prior art 
5 systems which only show the best dealable price or the best minimum quantity, 
the present invention shows all prices (bids and offers), inespeaive of their 
credit preferences. Thus, the user can be provided with as wide of a view of the 
markets as the user desires. Advantageously, the color coding enables the user to 
visually determine virtually instantaneously what bids and offers are tradable 
10 based on the credit preferences of the trader and the counterparty. 

Once the user has entered the desired financial instruments in the market 
entry interlace 250 via the symbology , the best bid and offers for each of the 
desired instruments will be displayed in the instrument display window 252. The 
best bid and best offer prices display in window 252 are different from many 
15 prior art systems because they are the absolute best bid atKi best offer at the 
stated quantity. Because of the unique color coding scheme, the user is able to 
quickly tell whether or not the bid or offer is tradable by hina/her. If the user so 
desires, the user can select a financial insmmient with the pointing device 86 
(FIG. 3), such as a mouse, so as to highlight the row in the instrument display 
20 window 252 for that instrument. Once the financial instrument is highlighted, 
the user may perform one of several functions provided for by the function bar 
290, each of which is described below: 

EXPL Function: This explodes the instrument symbol into a fiill 
25 description of the contract, and mirrors the confirmation 

mr, LIFT, ORD Functions: These three buttons allow a user to select an 
instrument and then place a new order, or execute an active order, 
by hitting or lifting the desired respective bid or offer. The HIT, 
UFT, ORD functions can also be carried out by double clicking 
30 the mouse in the screen itself. 
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RFP Function: request-for-price messages are an important tool to allow 
the ma±et to communicate. If a trader wishes to see a market, a 
broker will be contacted via the telephone, and the broker will in 
turn phone other traders to drum up interest. Using the system 10 

5 of the present invention, the same result can be achieved 

instantaneously by sending an RFP to all registered users. This 
message may be displayed in the command center inter&ce 130 of 
other users, informing them of a RFP in the named instrument. In 
addition, because derivatives traders are often trading more than 

10 one financial instrument, and sometimes in more than one 

currency, derivatives traders will often have multiple passive 
orders. The present invention provides at least three order 
management functions to facilitate the canceling or temporarily 
suspending the order. This may be an important functionality when 

15 the market is moving quickly, or if the position of a trader 

suddenly changes. 
XLST Function: This function cancels the last passive order placed by 
the trader. Therefore, if a user submits an order and immediately 
changes his or her mind, the order can be canceled without the 

20 need to select the order individually . 

XALL Function: This fiinction allows the user to cancel all his or her 

outstanding passive orders in one key stroke. 
REF Function: This function allows the user to suspend or place all 

orders under reference. This is an alternative to canceling orders 

25 one by one. For instance, if a user is expecting news that may 

affect only a few outstanding orders, it may be safer to place all 
orders under reference, and individually re-release the orders the 
trader expects not to be affected back into the market. 
DEL Function: This function allows the user to delete a market from the 

30 profile. 
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In specific rcgaid to the ORD button in tbe function bar 290, a user can 
submit a passive order by selecting the ORD button. If the ORD button is 
selected, a passive order imer&ce 294 is provided to the user, as illustrated in 
HG. 14A. From the passive order interface 294, the user can place a passive 

5 Older such as a bid (i.e., buy) or an ask {i.e., sell). The user enters a price, 
quantity, and selects how long the order will be good. The price will default to 
current market level so the user may only need to enter die last two digits of the 
price. For quantity, the system 10 recognizes m, mm and b for thousands, 
millions and billions, respectively. The system 10 allows the following order 

10 types to be entered under the good until option: 

good until logout (default) - Requires the user to be logged on and to 

monitor the orders status, 
good until time- The user will be prompted to enter a time (in his or her 
IS own time zone). This order does not require the user to be logged 

on and will be canceled automatically by the system 10 at the 

appropriate time. 

good until canceled - This order again does not require the user to be 
logged on, but must be canceled by the user. 

20 

The system checks any new orders for reasonableness (or "framing**) as they are 
placed. For example, a bid cannot be higher than the existing offer without the 
user double checking. The tab key, enter key, or the mouse can be used to 
navigate through the passive order interface 294. Upon selecting the OK button, 

25 the order is submitted into the system 10 and the user is returned to the market 
entry interface 250. 

In specific regard to tlte HIT and LIFT buttons in the function bar 290, a 
user can initiate active orders by hitting a bid {i.e., sell) or lifting an ask {i.e. , 
buy). By selecting either the HIT or LIFT button, a hit order window or a lift 

30 order window is presented to the user. For example, a hit order window 296 is 
illustrated in FIG. 14B. The hit order window 296 is substantially identical to the 
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lift Older wiixlow. As shown, the hit order window 296 identifies the instniment 
and order price. Further, the user is presented with a transaction quantity which 
is initially set for the fiill amount being offered by the counterparty. The user is 
allowed to reduce die quantity figure. The user is not allowed at this point to 

5 increase the quantity figure because the counterparty has already indicated the 
quantity they are desiring to sell. Upon selecting the OK button, the order is 
executed by the system in the manner described below, and the user is returned 
to die market entry interface 250. 

In addition to die above functions provided by the function bar 290, if the 

10 user wants to see the full depdi and breath of a particular market in a particular 
financial instrument, die user can select (e.g. , highlight) an instrument in the 
instrument display window 252 and then click on die MDS button 292. This will 
launch the market detail interface 302, as illustrated in FIG. IS for the 
highlighted instniment. 

IS The market detail interface 302 enables a trader to view essentially all the 

orders in the market for a particular instrument, both bids and offers. The bid 
orders are listed in a bid window 304 where the credit levels (e.g.. A, B or C), 
bid quantities and bid prices are provided. The offer orders (i.e., ask orders) are 
listed in ask window 306 where the ask prices, ask quantities and credit levels are 

20 provided. As with die market entry interface 250, the orders are color-coded 
with the appropriate credit preferences. This is a significant departure from 
many prior art systems which only show the best dealable price or blended 
prices. 

In the market detail interface 302, orders are individually listed in the bid 
25 window 304 or die ask window 306 in order of price, and then according to the 
time die orders were entered into die market. The user has die ability to select 
any order on die screen and hit or lift die order, assuming of course diat the 
respective credit preferences will permit a trade. The user is provided with a 
function bar 308, which is substantially the same as function bar 290. 
30 Particularly, the buttons of the function bar 308 are substantially identically to 
diose on die function bar 290 except diat diey only apply to a particular 
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iiistniment while the buttons of the function bar 290 apply against multiple 
mstniments. Further, a fair price indicator, spot/setting indicator (i.e. , the 
LIBOR for that day), and last traded price indicator are provided along the 
bottom of the bid window 304 and ask window 306. The last trade pricing may 

5 be replaced by volume, duration, RQ, last close price, etc. 

An advantage of the market detail inter&ce 302 is that the user is not 
restricted to trading only the best price or first order. At no point in the process 
will any orders be automatically matched against each other by the system 10. 
The user is in complete control of the order flow process. 

10 Thus, the user can execute both passive and active orders from either the 

market detail interface 302 or the market entry interface 250. At either interface 
250, 302, if the user wants to execute a trade, then the user only need to 
highlight the desired bid or offer and select the corresponding function button 
from the respective function bar 290, 308 to initiate the transaction. Although 

IS the semantics of placing, changing, and canceling orders can be relatively 
complex, the user is shielded from this wherever possible by the system 10. 

Each Older entered into the system 10 is placed into a queue based on 
price and time received. A change to the order may or may not affect the order's 
place in the queue. Any change of price will move the order up or down in the 

20 queue depending on tiie price level. Any decrease in the vohmie of the order will 
not affect the oider's place in the queue. Any increase in volume will result in 
the previous amount holding its place and a new order placed for the balance. 

Effective electronic trading should be intuitive, fiast and reliable. In order 
to focilitate this, the present invention is designed to maximize a user's 

25 efficiency. The system 10 enables tiie user to place passive orders from either 
the market entry interface 250 or market details inter&ce 302 using the input 
device 86. For instance, the user may double click on the instrument name or 
may select the ORD button of the function bar 290, 308 in order to launch the 
passive order interface 294. 

30 Once an order has been submitted, it will inmiediately be updated to the 

market entry interfaces 250 and market deuils interfaces 302 of other users, 
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providing the user has a current subscription (i.e., field setting) to the 
instrument. 

For monitoring the status of a user's outstanding (or open) passive orders, 
and for making quick adjustments to those orders, the present invention has a 

S facility known as an outstanding order blotter 320, as illustrated in FIG. 16. The 
outstanding order blotter 320 summarizes all outstandmg passive orders and 
provides the user with the ability to confirm the terms of the trade, the symbol, 
and the type of order. In addition, the outstanding order blotter 320 enables the 
user to quickly change the price, quantity, or good until status via drop-down 

10 menus that appear when an order is selected. From the outstanding order blotter 
320, the user may also place new orders and/or cancel a particular order in the 
market. Thus, the outstanding order blotter 320 gives the user the ability to 
manage his/her current passive orders in the market from a single interface. As 
with the market entry interface 250 and market detail interface 302, the user is 

15 provided with cancel all, cancel last, and refer-all functions via the outstanding 
order blotter 320. This is a significant advancement over many prior art systems 
in that not only does the system 10 offer a focility to track all current passive 
orders, but the system 10 also enables the user to modify, add or delete passive 
orders from the outstanding order blotter 320 without returning to the market 

20 emry interface 250 or market detail interface 302. 

For executed or canceled orders, the user is provided a client monitor 
330, as illustrated in FIG. 17. From the client monitor 330, the user has access 
to completed or canceled trades. Thus, the client monitor 330 enables the user to 
quickly see what orders have been executed or canceled, and to look back over 

25 time to see pervious days trades. Preferably, historical transactions will be 
available for one month via the client monitor 330. 

The outstanding order blotter 320 and client monitor 330 enable a user to 
manage his/her diverse trading activities. From either blotter, the user can 
monitor the status of orders and executed or canceled trades. Both of the 

30 outstanding order blotter 320 and client monitor 330 can be accessed from the 
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command center interface 130. Further, the blotter 320 and monitor 330 are 
updated automatically if the user submits an order via one of ib& other interfiures. 

The Systran 10 permits active orders (i.e. , those wtere a trader hits or 
lifts a passive order) to be placed from either the market entry mterface 250 or 

5 maricet detail interface 302 via the HIT and LIFT buttons on the function bars 
290, 308. The system 10 differs from many prior an systems in that two passive 
orders will not be executed against each other automatically. An active order 
from an active user is required for execution. Furthermore, there will be one 
active and one passive user for each trade. This means choice (where bid equals 

10 order) or even backwardation (where bid is higher than order) markets are 
possible. Accordingly, for a transaction to be completed in the system 10, an 
action must be performed against a passive order. 

Once an active order has been placed in the system 10, the execution 
process is completed. An execution notification message 340, as illustrated in 

15 FIG. 18, is sent to both counterparties, describing the transaction and disclosing 
the names of the counterparties. Note, this is the first point in the transaction 
that the counterparties are identified to one another. The system 10 ensures that 
both users receive the message before the Urade is fmally conq>leted. This does 
not require any form of action from either user, the market interface module 74 

20 (FIG. 3) of each trader responds for die respective user. This validation ensures 
that, in the unlikely event that a connection is lost during this process, a user 
does not have a position of which he or she is unaware. 

The system 10 is designed to ensure that a user cannot execute a passive 
order which has been canceled or is no longer available. This is done by 

2S checkmg to verify that the connection between all trading counterparties is live at 
all times. In the event that die connection is lost or broken, all orders from a 
user which loses connection to die system 10 are automatically suspended. 
Following the execution, die client monitor 330 is updated widi the transaction. 
The execution notification message 340 (FIG. 18) provides die users die 

30 opportunity to increase the quantity of a trade once an initial trade has been 
executed. One of the users can insert a quantity in the will-do-more field 342 
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which represents an additional quantity to the original amount. This feature is 
designed to enable a user who has a laige quantity to trade to place a passive 
order for just a smaller portion initially. Users often want die ability to increase 
the quantity of an order when they have a large quantity to transact. This is 

5 because large orders in the market often tend to adversely move the price of the 
market as market participants back off such large size. The ability for the 
passive trader to conduct an anonymous dialogue via the system 10 for increasing 
the size of a transaction after an initial transaction for a smaller size has been 
executed is an additional difference between the system 10 and many prior art 

10 systems. In operation, once an amount has been entered into the wilMo-more 
field 342 and the Submit button 344 selected, the counterparty is provided with 
the request for more. The counterparty is given a discrete period of time to 
respond to the request to do more, after which the request lapses. If the 
coimterparty wants to trade more, then the counterparty can accept the amount 

15 requested, reject the amount by selecting the Reject button 346, or the 

counterparty can request a different amount that is then present back to the user 
who then has a discrete period of time to respond. The counterparties can 
exchange offers to increase the quantity as many times as they desire until an 
addition amount is agreed upon or a decision is made not to do more. 

20 This function should preferably be made available only if the active order 

clears the fiill market size at the current best price, hi that case, eidier party may 
ask to do more. The will-do-more feamrc enables the counterparties to increase 
the size (amount of the trade), but not the price. The price is preferably not 
affected. This process can go back and forth for some time and can continue as 

25 long as the wilWo-quantily is fiilly accepted (/.e. can occur more dian once). 
Once completed by both parties, the system will combine all will-do-more 
quantities and generate only one transaction ticket for the total increased amount 
at the initial price. 

Following the execution of a trade, the system 10 enables the parties to 

30 negotiate the non-commercial terms of the transaction. This process is referred 
to as term negotiation, and is effecmated through the negotiation window 350, as 
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aiustrated in FIG. 19. The term negotiation process is a process where by both 
parties to a trade have tte ability to negotiate non-commercial terms of a 
transaction. In addition to the commercial terms, such as price, quantity, etc. , 
derivative transactions also have non-commercial terms which do not affect the 

5 price of the trade. While there are defaults, the parties may want to negotiate 
diese terms. Once a trade has been executed, the system 10 will present the 
parties with the option to negotiate via interface 350. The system does not force 
a party to conq)lete tiiis process immediately, however, as the party may have 
other more important tasks to complete elsewhere. The Mgotiation should, 

10 however, be completed within a reasonable time. The active party (/.e. , the 
trader that hit or lifted the order) will be presented with the terms 352 to be 
negotiated, cunent values 354 which are editable (such as by a text field), and 
default values 356 which are predefined in the system. The trader may accept the 
system defaults by selecting button 358, or enter his/her own desired values and 

15 select the submit button 360. These values are sent to the passive trader {i.e., the 
trader that placed the order in the system originally) who may also accept or 
enter his/her desired values. If an agreement cannot be reached, then the defaults 
will be used. The status of these negotiations will be displayed in the client 
monitor 330 of FIG. 17. 

20 Once a trade has been executed and the non-commercial terms have been 

negotiated, a trade confirmation is sent automatically to the settiement contact of 
both business units preferably via fax. The system 10 can also send the 
confirmation via file transfers, e-mail, or any other suitable means of 
communication. Preferably, the trade confirmation includes the quantity or 

25 vohmie traded, identification of the financial instrument that was traded, price, 
date and time the execution is recorded, and a settlement ID that uniquely 
identifies the transaction. However, it is recognized that various other 
parameters and transactional data can be included as appropriate for the nature, 
type and subject matter of the transaction. 

30 In addition to the interactive trading functionality described herein, the 

system 10 also offers traders a trading methodology for dealing with risk 
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managemeDt problems unique to interest rate swap dealers. In particular, over 
the last few years, a new market has emerged as a result of interest rate swap 
dealers' need to better manage their risks associated with changes in intmst rates 
on their growing interest rate swap portfolios. With these markets becoming 

5 more competitive, bid-offer spreads are narrowing considerably. This factor, 
combined with the wide spreads of exchange traded Eurodollar futures, has 
contributed to the use of exchange traded contracts for hedging short-term risks 
being expensive and subH)ptimal. As a result, the switch was created. A switch 
is simply the simultaneous purchase and sale of a pair of similar forward rate 

10 agreements. This instrument, and the mutually offsetting need of a pair of 
derivative portfolio risk managers, provide an improved risk management tool 
for a large portfolio of interest rate swaps. Despite the obvious advantages and 
demand from risk managers, as a result of the coirqplexity and time-consuming 
nature of completing a transaction, the switch market has grown relatively slow. 

15 This may be because risk managers are very wary of disclosing the exact nature 
and size of their own portfolios. Therefore, finding the counterparty that has the 
opposite need is often difficult. 

Typically, a dealer prepares a fax listing the days that the dealer needs to 
buy or sell, but not the amount or importance of any given date. The dealer 

20 sends the listing to other risk managers at other firms, or to voice brokers. From 
this bit of incomplete information, transactions are evenmally negotiated. While 
finding switches may be important, it is usually not urgent as compared to other 
more immediate tasks, such as new executions or the hedging of large outright 
market risks. As a result, the time is never quite right to focus on a position that 

25 may be heavily weighted on one side and matches another's position, but not 
perfectly. Voice brokers have tried to solve this by matching multiple faxes, but 
this does not ^pear to be the solution. 

The present invention goes several steps beyond these efforts, and offers 
matching with the credit preferences of the traders taken into account. The 

30 system 10 also demonstrates fairness in any matching process. When the 

portfolios are so large that each risk manager has a position on each day out over 
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the life of his or her portfolio, the resulting combinations can be huge. The rules, 
constraints and priorities are preferably structured in a way to demonstrate 
fairness of execution between users to the market participants. 

In a significant dq)arture from known attempts by others, the present 

5 invention offers traders a solution to the co^^)lexities of switch tradmg by 
creating an anonymous position discovery system called the switch engine. The 
objective of the switch engine is to put a tool in the hands of risk managers that 
allows diem to perform anonymous switch transactions fast and efficiently 
without losing control of the process. The switch engine achieves this by having 

10 the trader manually input his/her position {i.e., interest rate risk portfolio) into 
the switch module 80 (FIG. 3) via a portfolio interface 380 using variable rate 
index and currency for up to 180 days or more into the future, as illustrated by 
FIG. 20. Once a portfolio is inputted, the user must confirm its accuracy by 
selecting the Apply button 381 before the positions can be used in the switch 

15 mechanism 35 of the central processing center 12 (FIG. 2). 

In addition, the system 10 can be configured to receive the position data 
via electronic transfer or some other suitable form of data transfer. This may 
include a transfer directly from tiie user's own risk management systems. 
Aldiough some trader workstation 20 may need some customization to receive 

20 portfolios in this matter, the system 10 should support this capability. The nature 
of switch positions, particularly in the near term (defined as out to the maturity of 
each index), is relatively stable, and therefore, the on-liM entry of portfolios by 
the user should be adequate for most traders. The mputted portfolio data is then 
sent from the trader 20 workstation to the switch mechanism 35 of the central 

25 processing center 12. 

With reference to the portfolio interface 380 of FIG. 20, an ia^msd 
column 382 represents the portfolio entered by the user, the traded column 384 is 
the cumulative amount traded by the user since the portfolio was entered in the 
inputted column 382. The net column 386 is the real-time position of the user 

30 given the portfolio inputted and the traded quantities in column 384. The user 
may restart at any time by rolling the net positions in net column 386 into the 
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input column 382 by selecting the Roll button 388, or by clearing all the 
positions by selecting the Clear button 389. 

Once the position is inputted in the system 10, a switch interface 400, as 
iUustraied in FIG. 21, is generated by the switch module 80 using his/her own 

5 position data from other traders entered on the respective trader woriatations 20 
aid uploaded to the switch mechanism 35. The switch interfoce 400 enables the 
user to search through the market, and view possible trading combinations of 
his/her portfolio and combinations of his/her portfolio against positions from 
other counterparties which have been input into the system. This is referred to as 

10 position discovery. The switch interface 400 can be reached by selecting the 
switch engine button in the tool bar 132 of the command center interface 130 
(FIG. 5). For a given floating rate index (for example, a one month UBOR) 
402, the switch engine interface 400 lists the net positions 404 for each day 406 
out 180 days. In addition, the possible switches 408, available switches 410, 

15 formulated forward rate 412, and a fair price 414 are also listed for each day 
406. By selecting a day 406, the switch interface 400 displays all possible 
switches against that day. Thus, the user can pick the days for which he/she is 
carrying the most risk. An advantageous feauire of the switch interface is that 
the user is provided with only combinations where he/she has a position and 

20 someone else has the opposite position, and both parties satisfy each other's 
credit preferences as described above. 

The net position 404 is the position entered or modified by the user. 
Possible switches 408 are those switches for any given day with respect to the 
trader's own position. Note, a switch typically makes sense only if the trader's 

25 position is long one day and short on another day. 

The available switches 410 are positions in other counterparty portfolios 
that exactly offset the position of the user. Note that the switch interface is 
configured to displays available switches up to the size of the user's own 
position, and preferably does not disclose the name(s) of any counterparties until 

30 after a trade has been completed. This ensures the anonymity of the user, and 
does not disclose any material position data to other traders. 
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The forward rate 412 is the current market forward rate calculated by the 
system from other available market rates for the given date for the maturity of the 
underlying index maturity. The fair price 414 represents the relative price 
between the two underlying FRAs, which is the basis i^on which forward rate 
S agreements are traded. The fair price 414 is calculated from live market data 
taken from other fmancial instruments. While not designed to execute trades at 
the displayed fair price 414, the fair prices are an aid to users in gauging the fair 
value of the market. 

Once a user has found a switch that matches the needs of the user, that is 

10 shown as an available switch 410, then the user may send a request for switch 
message by selecting the request for switch (RFS) button 416. In response 
thereto, an RFS message is sent anonymously to only the other counterparties of 
the selected offsetting positions. Anyone of the receiving counterparties may 
then add the symbol automatically into a market entry profile by selecting (i.e., 

15 clicking on) the message and completing the transaction utilizing the market entry 
interface 250, as described herein. Upon conq)letion of a switch by the switch 
mechanism 35, the portfolio's of the counterparties are automatically updated to 
reflect the switch. In accordance with a feature of the switch engine, switch 
transactions can be accon^lished in real-time. 

20 As an example of a switch, a trader viewing the switch interface 400 may 

select (/.c, highlight) the "Thurs., Aug. 21" position, and then select the RFS 
button 416. The passive order interface 294 (HG. 14 A) then prompts the trader 
with a quantity and price which the trader may modify. The trader may then 
submit the request for the switch. All anonymous counterparties tiiat have an 

25 offsetting position then receive a message in command center interface 130 (FIG. 
5) notifying the counterparty of the anonymous request for a switch. Any one of 
the counterparties may then select the request message which causes the request 
to be displayed in the market entry interface 250 (FIG. 12). From the market 
entry interface 250, the counterparty can hit the request for switch or submit their 

30 own passive order. 
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The trader can update or modify his/her portfolio by selecting the Update 
button 418, which launches portfolio inter£ace 380, as described above. The 
trader can then select an iiqiutted amount 382 or a traded amount 384 to enter or 
edit the displayed vahies as desired. 

5 It should be noted that the present invention has application in financial 

markets other than derivatives. For instance, in the inter-dealer market, a switch 
or sw^ may be a desirable means by which a risk or inventory short fall is 
off-set. In particular, a security may be borrowed or an open derivative position 
hedged with another position. For instance, in the U.S. Treasury bond market, it 

10 is conventional for traders to buy and sell securities, and to hedge with the 
newest or benchmark issues. The U.S. Treasury may issue new two year 
securities each month. For the first month, the new issue is the benchmark (or 
on-the-run) issue, and the other issues with a final maturity between one and two 
years are referred to as old issues. If a trader is asked to buy an old issue, then 

15 the trader will sell the on-the-run as a hedge since the on-ihe-run has the 

liquidity. Over time, the trader will most likely need to sell the old issue and buy 
back his/her hedge. A switch with another dealer that has an opposite position 
provides cost and risk effective method of efBecmating such a trade. 

However, the unwillingness of traders to disclose their position has made 

20 bond switches difficult. Thus, die switch engine of the present invention is a 
solution. The principals of the switch engine can be successfully applied to bond 
switches, as well as other financial instrument switches. The switch engine 
interface 400 may need to be slightly modified wherein the instrument 
designation 402 is changed to reflect the new market, for instance, to Two Year 

25 U.S. Treasuries or 30 FHLMC TBA. Further, the setting column 406 may be 
changed to reflect the individual securities which may be switched, and the 
remaining columns should not need to be changed. However, a new colunm 
representing the duration of each security displayed should be added so that the 
securities can be duration weighed to ensure fairness. 

30 In addition to the switch engine, the system 10 provides trading 

methcxlologies referred to as the auction and switch auction. Although auctions 
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are held in a variety of niarkets, some of which are electronic, the auction and 
switch auction have no known counterpart in the derivatives markets. The auction 
and switch auction trading methodologies were developed in order to provide an 
auto matching process for switches. However, the system 10 can use these 

5 auction methodologies for auto matching for a wide variety of odier financial 
products, not just switches. 

Unlike traditional auctions, where once a trade is conq)leted the 
counterparties are free from future financial commitments, with derivatives 
trading, the counterparties may end up with multi-year financial commitments to 

10 one another once a trade is executed. In order to deal with this relatively unique 
problem, the auction and switch auction take the credit preferences of the users 
into account. The auction methodologies herein are referred to as a two way 
Dutch auction with credit. In conducting such an auction, users submit orders 
into the auction module 81 of the trader workstation 20 (FIG. 3) which 

15 communicates the information to the auction mechanism 34 of the central 

processing center 12 (FIG. 2). The orders are submitted via an auction interface 
430, as illustrated in FIG. 22A, by price, quantity, and action. 

With refierence to FIG. 22A, the auction interface 430 includes a queued 
orders window 432 into which the user enters an order, and a submitted orders 

20 window 434 which shows the orders submitted to the auction mechanism 34 via 
the auction module 81. Orders can be added via the Add button 436. Orders are 
moved from the queued orders window 432 to the submitted orders window 434 
by highlighting the order and then selecting the Submit button 438. All entered 
orders in the queued orders wmdow 342 can be submitted at once by highlighting 

25 ail the onlers and then selecting the Submit All button 442. Prior to submitting 
an order, the orders in the queued orders window 432 can be edited via the Edit 
button 440 or canceled via the Cancel button 444 

In accordance with the auction, the orders are filled at their entered price 
or better, and between counterparties that satisfy the credit preferences of one 

30 another. The auction mechanism 34 then conducts the auction, preferably 
utilizing the following constraints and priorities to ensure fairness. 
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The auaion price is calculated by finding the price at which the most 
volume is traded. This condition is sufficient to generate a fan- price, and all 
transactions should be completed at this price. It is noted that this price is 
generated without taking credit into account. The matching of orders is 
5 conq)leted to ensure that credit preferences (including con$)lex rules) are safe 
guarded and to ensure that the minimum number of tickets are generated. The 
better submitted prices will have priority, and all orders at the auction-price are 
filled in proportion to each other. Under these constraints, the auction 
mechanism 34 executes the auction, matching users and generating a setdement 
10 list. The settlement list comprises the trades resulting from the auction. 

The confirmation process is substantially the same as that for interactive 
trades. The system 10 notifies the users of their fills. Finally, results will be 
made available to the user via a message to the command center interface 130 of 
each user. 

15 In addition to the general auction facility described herein, the present 

invention also offers a dedicated limited auto-matching process for switches 
referred to as the switch auction. The switch auction does not have to be a lull 
auction, in that the price may be set by the system 10. The price will, however, 
be available before the conunencement of the matching. This will allow all users 

20 to understand the levels that will be used before entering into the switch auction. 
This also allows the users to maintain control of their positions. 

As with the general auction, the positions of each trader are loaded into 
the system 10 utilizing a switch auction inter&ce 460» as illustrated in FIG. 22B. 
The switch auction interface 460 has two parts, an auction list 462 and an auction 

25 status 464. In the auction list 462, various auctions and their respective statuses 
are listed by FLOPT and currency. In the auction status 464, the auction selected 
in the auction list 462 is displayed and identified (including the open and close 
day/time). The positions 466 for respective dates 468 are entered by a user, and 
do not need to add to zero, but should include positions of both signs (z.e. , long 

30 and short). The rate 470 is the price at which the auction is conducted. The rate 
470 is displayed a predetermined amoum of time before the auction is conducted 
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SO that the paiticipants have the oppoitunity to step out of the switch auction if 
they so desire. The rate is preferably based on available market factors, and may 
be calculated by a calcserver (as described below). The results column 472 is the 
total trade amounts resulting from the auction. The amount displayed in the 

5 results colunm 472 for a given date may be the cumulative amount from multiple 
transactions with multiple parties. Additional control buttons 474 enable the user 
to submit an order, cancel an order, cancel all orders, or change an order. The 
switch auction will auto-match the position, taking credit preferences of the users 
into account so that (1) a maximum volume is executed and (2) a minimum 

10 number of tickets is generated. 

The switch auction utilizes the above two rules to ensure fairness. No 
user will be given priority over any other user except as required to satisfy the 
respective credit preferences. Preferably, only two-way switches will be 
offered. Switches are a risk management tool» and switches generated between 

IS three counterparties introduces substantially more credit risk than a straight two- 
way switch. 

At this point, die calcserver which calculates the auction rate and price 
information, and odier relevant data for operation of the system 10 is described. 
The calcserver provides die switch mechanism 35 with the forward rate for any 

20 given index for each day, the system price quoted in the market entry interface 
250. and OTC derivative prices derived from the yield curve. The calcserver 
comprises a preprcxressor, a zero curve server, a FRA server and a Swap server. 
The preprocessor gathers real-time data from outside data vendors (such as 
Renter or Telerate) and from internal system sources (such as data normally 

25 entered into system 10), aiKl prepares the data for processing by the other 
components of the calcserver. The zero curve server reads in the market rates 
(including price and yield for a variety of class instruments such as money 
market rates, swap rates, future prices, swap spread, bond yields and FRA's) as 
provided by the preprocessor, and generates therefrom the zeros and discount 

30 factors for each currency and level of credit. In particular, a zero coupon yield 
curve (i.e., zero curve) con:^)rises a set of points representing the calculated 
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interest rate or discount hct from observable market rates across the term 
structure (e.g. , 0 to 30 years) such that any cash flow can be discounted to today 
in one step without the consideration with deconq)ounding. Thus, there is a 
different zero curve for each index/currency pair. The FRA aiKl Swap servers 
5 are instrument specific servers that calculate forwards, RQ (as defmed above), 
durations and fair prices. 

By way of exan^le. the zero curve calculation starts from the instruments 
with the shortest term structure in the money market rates (MMs). The analytics 
for finding points on the zero curve from MMs are as follow. The processed 

10 price of the MMs, end date of the MMs and the basis of the MMs (number of 
days in a year that the MMs is based on) are needed. All of these are stored in a 
database 64 (FIG. 2). The processed price is the only input that typically 
changes. The calculation represented by the equation below will generate a new 
zero rate with the date of the end date of the MMs. The result will be a new zero 

15 point which will be added to the rest of the generated zero points. The followii^ 
equation for Z(t) is the zero rate at the end date of the MMs: 

where Rnuns is the processed price of MMs, and t is the time in days between 

20 the end date of the MMs and the current date. 

After the MMs, the next instruments used according to term structure are 
either the futures or FRA's. Since the futures and FRA's have similar term 
structures, a choice will be made on which ones to use. Initially the futures will 
be used because they have high liquidity. However, it is believed that when 

25 FRA*s traded on the system 10 reach a high level of liquidity, they should be 
used instead. 

When calculating zero points from the futures, the processed price, the 
fumre basis (number of days in a year that the future is based on), the start date 
of the future, the end date of the future and the zero point of the start date are 
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needed. This data about the future will come from the preprocessor which is 
used to represeot the future. The zero point at the start date is found from 
previous zero points through interpolation. The following equation for z(e) is the 
zero rate at the end date of the fuuire. 



Vifh&TtJutBasis is the number of days in a year that the future is based off, futRate 
is die processed price of the fumre, e is the end date minus current date, and s is 
the start date minus the current date. 

The calculation of the FRA zero points is the same as for the futures 
except that the processed price for the FRA and the FRAbasis are used instead of 
the processed price for the future and the futurebasis. The information about the 
FRA will come from the preprocessor. The following equation for z(e)f„ is the 
zero rate at the end date of the FRA: 



The rest of the zero curve will be derived from swap information. For 
the first swap, the zero curve and the discount factor at each coupon date are 
used to calculate the zero rate and the end date in the swap using the equation 
below for Z(t„). When calculating other swap zero points, gaps may exist in the 
zero curve. Synthetic swap rates are calculated where gaps exist to improve 
accuracy. The calculation of a normal swap rate and a synthetic swap rate are 
the same. The following equation for Z(ti) is the zero rate at the particular 
coupon date: 
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Uswcq)Rate*Y{tn-[,tn 

where swapRate is tradePriceAdjust, t; represents a coupon date, and Y(t^i,t^ is 
the period in years between the two coupon dates. Once the trades have been 
executed and the term negotiation process completed, the system will initiate an 

5 automatic confirmation process which, in an embodiment of the present 

invention, will follow existing market practices. Accordingly, the system 10 will 
automatically send a fax confirmation message to each counterparty detailing the 
transaction. The faxes should be sent immediately after a transaction is 
completed. The confirmations should follow a unique format, allowing the 

10 automatic transfer of these confirmations electronically. 

This confirmation has been specially developed to allow for a standard 
format covering all classes of financial contracts. The standard confirmation 
follows the following format: 



365 //„ 

-I 



15 Section I: Summary of the transaction. 

Section 2: Counterparty details and conunission. 

Section 3 : Transaction details . 

Section 4: Term negotiation 



20 This provides the users with adequate information to identify and/or record the 
transaction. The conformation, however, may be sent to the traders any number 
of ways such as via e-mail, voice-mail, United States Postal Service, or 
commercial carrier (e.g., FedEx, UPS, etc). Further, it is noted that the 
information provided can take many other formats widim the scope of the present 

25 invention. 

While the various interfaces to system 10 have been described herein as 
individual windows, it is noted that multiple windows can be integrated to form a 
main screen 480 with multiple frames, as illustrated in FIG. 23. For instance, a 
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tools area 432 provides the trader with a set of customized tools including 
graphs, market quotes, bond prices to yield converters, pricing tools, and 
MarketSheet™ applets. A service area 484 provides various interfaces as 
described above on a temporary basis. A message center 486 displays the most 
5 recent RFP, RFS, Chat and administrative messages, and is preferably 
configured as a drop-down window to display multiple current messages. A 
status bar 488 displays user status information. A workspace area 490 provides 
for the entering of data into dialog boxes in a non-mtrusive manner, plus the 
execution of the data function. A warehouse area 492 stores the most commonly 
10 used interfaces in a tabbed format, allowing the trader to retain their preferred 
set-iq) between sessions. Accordingly, the main screen 480 provides enhanced 
functionality by integrating multiple interfaces in a single window. 

15 IV. Operation 

As described above, the system 10 comprises the central processing center 
12 that may includes multiple servers connected via an Internet-protocol network 
to the individual counterparties trader workstation 20 which may be desktop 
computer workstations. Because of the open system architecmre of the system 

20 10, the present invention may nm within the context of the internet browser 72 
on the user's existing desktop compiuer 20. The desktop computer 20 preferably 
includes an operating system platform for which a Java-enabled Internet browser 
is available. 

In order to provide the counterparties widi anonymous credit preference 
25 based trading capability for a wide range of fmancial contracts where each side 
enters into a long-term contract with the others, the present invention is designed 
to be flexible enough to reflect several different measures of credit risk, as 
generally described below with reference to FIG. 24. 

With reference to flowchart 502 of FIG. 24. each business unit 
30 (counterparty) provides the group server 32 (FIG. 2) with detailed credit 
preferences for each potential counterparty business unit's legal entity. The 
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group server 32 then distributes the credit preference information in an 
anonymous format to the trade workstation 20 which uses the credit preferences 
of each active business unit (counterparty) in the systm 10 to prescreen the 
user's market orders (bids and offers) against the other counterparties' market 

5 orders. Thus, the credit preference module 76 (FIG. 3) of each trader receives 
the credit preference information defined by a first user with respect to a second 
user, as indicated by block 504. The credit preference module 76 then receives 
the credit preference information from the second user with respect to the first 
user, as indicated in block 506. The credit preference module 76 then detennines 

10 which orders, on which financial instruments, and with which counterparties, the 
user can deal. This information is coding on the posted prices utilizing color or 
another notational method such as symbols, as indicated in block 508. 

In accordance with an aspect of the present invention, the prescreening is 
a complex check to determine whether two particular counterparties will accept 

IS each other for a particular class of fmancial instrument, for a particular amount 
and for a particular maturity. This is a risk equivalent measurement, and is more 
than a simple yes/no preauthorization matrbc. More specifically, because each 
fmancial instrument has different credit qualities, it is possible for a particular 
counterparty to be willing to accept another particular counterparty for one type 

20 of financial instruiment but not another. Furthermore, it is also possible that a 
particular counterparty may accept the other for a particular financial instrument, 
but only for a certain length of time {i,e,, maturity). The system 10 may also 
allow the user to accept counteiparties for different amounts at different 
maturities. 

25 It is further noted that the system 10 divides counterparties into legal 

entities. These legal entities may be further divided into individual business 
units. So, for example, Bank A may be a legal entity (counterparty) and Bank A 
might have a different business unit in three different cities (e.g, , Tokyo, 
London, and New York). In this example, the counterparty credit information is 

30 available at the legal entity level. So, for instance, if Bank A wishes to allow 
each of its business units to set their own credit preferences for other 
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counterparties, then these credit preferences will be listed against the legal entity 
level of all the other business units. In other words, business unit A at Bank A 
can not say it will trade with desk A of Bank B but not desk B of Bank B. The 
system 10 allows business units within a particular legal entity to inherit the 
5 credit preferences from other business units in the same legal entity family, if so 
desired. 

Once each business unit has inputted their individual credit preferences, 
this credit preference information is maintained locally at the inputting ttader 
workstation 20, and transmitted to the group server 32 of the central processing 

10 center 12. The central processing center dien transmits a vector of encoded 
credit preference data to each user logged on, wherein the data represents that 
preferences of the user to the other legal entities and the preferences of other 
business units to that user's legal entity for the affected instrument classes. The 
encoded vector of credit preference data is accessible to any of the u-ader 

15 workstations 20 in the system 10; however, the sensitive credit information of 
other counterparties is not available. 

Once the user has ii5)utted his/her business unit's credit preferences, the 
user is then able to select or filter messages on which financial instruments and in 
which currencies the user wishes to receive updates, messages and prompts. The 

20 fdters can be selected via the user preference interface 148 to customize the order 
information presented by the command center interface 130. This screening 
capability is provided to die user in order to prevent him from being 
overwhehned by. and to sort through, the possibly thousands of different 
financial instruments in up to or more than 14 different currencies that the system 

25 10 has the ability to handle. Once these filters have been iiq)utted imo the system 
10, the user is able to view trading information on the currencies and financial 
instruments that have been selected for the user. This means, for example, that if 
the user has selected US dollars only, then the user will preferably not see 
information on the Japanese Yen financial instruments which are in the system 10 

30 for trading. 



-83- 

SUBSTTTUTE SHEET (RULE 26) 



wo 99/19821 



PCTAJS98/21518 



Once the trading preferences of the user have been entered into the system 
10, the user can proceed with trading. The user then activates the fully 
customizable, re-sizable market entry interface 250. The market entry interface 
250 enables the user to input many different financial instruments which the user 
5 is interested in trading on one screen, and have any number of profiles wherein 
each profile is a collection of markets or a collection of financial contracts in the 
system 10. 

A preferred embodiment accomplishes the inputting and referencing of the 
various financial instruments through the use of a unique set of symbols referred 

10 to as symbology. The symbology of the present invention is based on a concept 
of subject based addressing whereby the user creates a symbol to uniquely define 
any one of many complex financial instruments. The symbol denotes the financial 
instrument's parameters and attributes. The standardized symbology of the 
present invention is designed such that the users of the system 10 will recognize 

15 the meaning of the symbol when the users view the symbols. To fiirther help the 
users understand which financial mstrument they are trading, a symbol may be 
identified by the fiiU subject name, an alias (in the case of the most commonly 
traded mstrumems), or a unique identifier (e.g., such as a numeric code). In 
order to help the users use the symbology to properly express the financial 

20 mstruments they want to trade, the system 10 allows the users to construct 
symbols milizing the symbol construction interface 270 (FIG. 13). 

The symbology of the present invention, as described below and as 
illustrated flowchart 510 of FIG. 25, enables a user to input data including a 
proposed trade of a financial instrument, wherein the financial instrument is 

25 advantageously defined by symbology comprising a source field, a class field, a 
symbol field and a currency field, as indicated by block 512. This abbreviated 
format for identifying a financial instrument can then be easily transmitted to 
other users within the system 10, as indicated by block 514. At the receiving 
users trader workstation 20, the proposed trade can be viewed by the traders 

30 utilizing the symbology, as indicated by block 516. By defining the financial 
instrument using the symbology of the present invention, the users can exchange 
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a small amount of data that is translatable into a detail descrq)tion of a financial 
instrument tbat is relatively complex. This reduces communication and 
processing overhead of the system 10 and simplifies the user's efforts. 

Once the orders have been inputted via the symbology, the market entry 

5 interface 250 displays the best bid and best offer for each instrument, as well as 
the sum quantity available to trade at the best price and other relevant 
information. The order information (i.e., the bids and offers for each 
instrument) is coded with the relevant credit preferences, unless several prices 
are currently posted at the same price but have different credit status, in which 

10 case the market detail interface 302 should be used. This is significantly 

different from some prior art systems which only show the best dealable price. 
The system 10 presents the best price, irrespective of credit preferences or credit 
limits. From market entry interface 250, it is possible for the user to execute a 
trade directly if the credit preferences of both parties permit. The user may also 

15 place a passive order from the market entry interface 250. 

The user also has the option of activating a market detail interface 302 
which enables a user to see the complete picture {i.e., depth) of all the orders 
(e.g., bids and offers) available on a particular financial instrument, coded with 
credit preference information. The market entry interface 250 and the market 

20 detail interface 302 not only display the best bid and offer, but each individual 
order in the system 10 individually. Through the market entry interface 250 and 
the market detail interface 302, the user is provided the ability to select not just 
the best bid or offer, but any bid and offer in the system 10. This is important 
because for credit reasons, the viewing counterparty may not wish, or may not be 

25 allowed to, trade a particular bid or offer. This means that the best bid or offer 
in the system 10 is not necessarily the best bid or offer available to that 
counterparty. 

The credit preference information entered in the system 10 by each user, 
as described above, is used by both the central processing center 12 and the 
30 transmitting business unit servers 18 to prescreen the bids and offers, and to 
market orders in the system 10 before they are viewed at the trader workstations 
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20 of the respective client sites 14. The sensitive credit preference that indicates 
which counterparties are acceptable, and under what terms, is preferably 
maintained at the transmitting trader workstation 20 and the central processing 
center 12. The other viewing users do not receive or have access to the credit 

5 information of the other users. At the receiving business unit's server 18, a 
check is performed to determine whether the receivmg client site 14 will accept 
the particular bid or offer from the transmitting legal entity. The summary and 
relevant data is transferred in an encrypted form to trader workstations 20. The 
credit check may be re-performed at the time of a transaction by the central site 

10 14 and/or the central processing center 12. 

The credit preference screening of the present invention enables die 
display of all passive orders in the system 10 and their relevant credit status with 
regard to the viewer on bodi the market entry interface 250 and the market detail 
mterface 302 as follows: 1) green - this means diat the viewer accepts the 

15 posting counterparty, and the posting counterparty accepts the viewing 

counterparty; 2) yellow - this means that the viewing counterparty will accept the 
posting counterparty but that the posting counterparty will not accept the viewer; 
3) red - that the viewer will not accept the poster; 4) blue - that the bid or offer 
being looked at is the viewer's own; 5) white - used on the market entry interface 

20 250 to denote when two or more orders are placed at the same price but with 
different credit preferences. The use of color coding enables the system 10 to 
preserve the anonymity of the users while still enabling the viewing business 
units to receive credit information about the bids and offers they are viewing. In 
the event the user is color bUnd, die system 10 also includes the option to display 

25 small symbols next to each price to indicate the relevant credit stams to the 
viewer. 

If the viewer wants to trade a green bid or offer, then the system will 
permit this to be executed right away. Further, if the active counterparty to die 
transaction, tiiat is, die viewer who hit the bid or lifted die offer, chooses to 
30 execute the full size of die amount on offer or bid and diere are no more orders at 
the same price, the viewer will be prompted with the ability to ask the other 
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counterparty to do more. This will-do-more feature is preferably restricted to a 
predetermined time-limit ia which the receiver of the request must respond. The 
receiver of the request may agree to accept the increased quantity (or part of the 
increased quantity) at the previously agreed to price or the request will lapse. 

5 The will-do-more feature may be repeated as many tunes as the users desire. 
The will-do-more feature does not necessarily check credit preferences once this 
process has begun because both users know the identities of each other at this 
point. This forces the users to take responsibility for fiuther credit approval 
beyond the point of the initial trade amount. 

10 If the order being viewed by the user is yellow, then die viewer will 

accept the poster but the poster will not accept the viewer. In this case, the 
system 10 enables the viewer to send a credit override message to the poster of 
the bid or offer whereby the sender of the credit override reveals his/her identity 
to the poster and asks die poster to reconsider whether or not the poster will do 

15 the requested trade with the viewer. In diis case, die user which sent the credit 
override will be identified to the poster, but at no time will the sender of the 
credit override find out who they revealed themselves to. If the poster chooses to 
accept the credit override, then the poster may also choose to impose additional 
credit requirements on the viewer in order to accept the transaction. These 

20 addidoual credit requirements would be in the form of a standard mutual put 
clause in the confirmation of die trade. The viewer will have the opportunity to 
eidier accept or decline the additional credit requirements. The credit override 
function does not in anyway change the credit preferences which each user 
previously inpm into the system 10. The credit override is preferably on a per- 

25 transaction basis. 

If the bid or offer viewed by die viewing trader is in red, dien die viewer 
will not accept the poster. Despite the fact that the viewer knows he/she will not 
accept the poster, the viewer does not know which among the counterparties 
he/she will not accept is the poster. The viewer is thus not able to identify the 

3D poster, preserving die anonymity of the system 10. If the poster does not activate 
the credit override, then no trade will be able to take place. 
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If the bid or offer displayed is in blue, then the order is the poster's own 
order. The system 10 does not prevent different users within the same client site 
14 from trading with each other. 

From both the market entry interface 250 and the market detail interface 

5 302, it is also possible for the user to send a request-for-price message to the 
other counterparties that are interested in the requested financial instrument. The 
request-for-price enables a user to anonymously broadcast to other interested 
market participants. 

With reference to FIG. 26, a flowchart 520 generally describes the steps 

10 of a trade. Initially, the fu*st user and the second user are provided with 
essentially real-time order information regarding more than one financial 
instrument typically via the market entry interface 250, as indicated by block 
522. The order information preferably includes a request to buy or sell a 
financial instrument such as an OTC derivative. At block 524, one of the first or 

15 second users initiates the trading process on an order selected fix)m the order 
information provided by the other of the first or second users. The credit 
preference information of each user is then used to verify the trade eligibility of 
the first and second users with regard to one another based on the selected order, 
as indicated by block 526. One or both of the first and second users are then able 

20 to request an increase in the quantity of the order, as indicated by block 528. If 
an increase is requested, the request is process at block 530. Alternatively, if 
there is no request to increase the quantity at block 528, it is then determined that 
block 532 if there is a request to negotiate terms of the order, and more, 
particularly, the noncommercial terms of the financial instrument underlying the 

25 order. If there is a request to negotiate terms by one of the users, then the 
request is processed at block 534. If there is not a request to negotiate terms, 
then an acknowledgment is sent to both users signifying the execution of the 
trade, as indicated by block 536. 

The trade process as described above with reference to FIG. 26 can also 

30 be described from the perspective of the first and second users. For instance, 
with reference to FIG. 27A, a flowchart 540 generally depicts the steps of a trade 
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from the perspective of a passive user. Initially, at block 542, the credit 
preferences of the user are inputted and distributed to the other users for 
effectuating the credit preference screening. At block 544, the user sends an 
order to system 10 for distribution to the other users requesting a trade on a 

S financial instrument. The user that placed the order must then wait for another 
trader to hit or lift the passive order, thereby executing the trade. Both parties to 
the trade will receive an execution notification which will allow one or both users 
to request an increase in quantity, as determined by block 548. If this request is 
received from the party hitting or lifting the passive order, the first user accepts, 

10 denies, or amends the requested increase, as indicated by block 550. If there is 
no request to increase a quantity, then it is determined at block 552 whether there 
is a request to negotiate terms of the financial instrument. This feature allows the 
users to change the default values for the non-commercial terms of the financial 
contract, as indicated by block 554. Next, the first user will receive an 

15 acknowledgment of the execution of the trade with the second trader, as indicated 
by block 556. 

With reference to FIG. 27B, a flowchart 560 generally illustrates the steps 
of a trade from the perspective of the active user that lifted or hit the passive 
order. At block 562, the second user receives an order from the first user 

20 requesting a trade on a financial instrument. The order is then checked for trade 
eligibility based upon the credit preferences of the first and second users, as 
indicated by block 564. The order is coded with appropriate credit information 
based upon the credit check, as indicated by block 566. The coded order is then 
presented to the second user based upon a preference or filter set by the second 

25 user to view orders of the present instrument, as indicated by block 568. The 

second user then initiates a trade by lifting or hitting the order, as indicated by 

block 570. In block 572, it is determined if there is a request to increase 

quantity. If there is not a request to increase quantity, then the request is 

processed at block 574, If there is not a request to increase the quantity, then it 

30 is determined at block 576 whether there is a request to negotiate terms of the 

» 

financial instniment. This feature allows the users to change the default values 
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for die non-commercial terms of the financial contract, as indicated by block 577. 
Next, an acknowledgment is received by the first and second users indicating that 
the trade has been executed, as indicated by block 578. 

Another feature of the present invention is the position discovery as 

5 illustrated by a flowchart 580 of FIG. 28. At block 582. risk position portfolios 
are received from the users of system 10. At block 584, relative position 
information is calculated for each user so that each user may be presented with 
possible trading combinations for their portfolios, and combinations of their 
portfolios against positions from the other users. The possible trading 

10 combinations are coded with credit preference information in accordance with the 
present invention. It is then determined at block 586 if a switch is requested. If 
a switch is not requested, then the process ends. However, if a switch is 
requested at block 586, then a switch is executed at block 588. The execution of 
the switch is performed in substantially the same manner as any other trade, as 

15 described above. Upon execution of the switch, the position information of each 
party to the switch is automatically updated to reflect the switch, as indicated by 
block 590. 

A blotter is provided to enable the user to keep track of all the orders 
he/she has inputted into the market. The blotter is preferably a screen whereby 

20 once it is activated, it displays all the outstanding orders a user has in the system. 
The blotter enables the user to monitor all his/her outstanding orders in many 
different instruments conveniently in one place. Preferably, there are two types 
of blotters. The first is the outstanding order blotter 320 which offers several 
functions to the user for managing his/her orders, such as the ability to change 

25 the price, or size of an order. This is accon?)lished through the use of dials on 
the windows which enable the user to quickly dial up or down the price without 
needing to cancel and then re-subrait the order. This edit process shields the user 
from the complexity of order management regarding changed orders. This also 
prevents the user from accidentally having duplicate or no orders in the system 

30 10. The outstanding order blotter 320 also enables the user to quickly suspend 
(or refer) all of his/her active orders in the system 10, and then re-input them one 
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by one or delete them as necessary. Yet further, the outstanding order blotter 
enables the trader to cancel one or all of his ordm. The second type of blotter is 
the historical order blotter 330. From the historical order blotter, it is possible 
for the user to view all of his/her previously executed trades and the respective 

5 status, as well as those that have been canceled. 

In order to address the needs of interest rate swap traders and portfolio 
managers, the system 10 may include a function known as the switch engine. 
The switch engme is implemented by a switch interface 400 and enables the user 
to input an entire portfolio of interest rate reset risks into the system 10, and then 

10 view out into the future for an unlimited time horizon on a daily basis. In a 
preferred embodiment, the user inputs the size (in millions) and the direction 
(receiving or paying) of the reset risks portfolio into the system 10 on a wide 
range of the most common interest indices {i.e., 1 month US dollar libor, 3 
month US dollar libor, 1 month DEM libor, etc.). The portfolio can be irq)ut 

15 either directly through the portfolio interface 380 (FIG. 21), or by uploading a 
file with the required information. Once the information has been vapvx into the 
system 10, the user is then asked to confirm the input. Once this information has 
been confirmed, the user then has the ability to anonymously look at his/her 
interest rate reset risk position relative to all other counterparties who have 

20 inputted such information to determine based upon credit preferences, which 
trades are available to him/her in the system 10 to off-set his/her interest rate 
reset risks. Once the user has located these trades, the user can then 
anonymously send a rcquest-for-switch to the other counterparties in an attempt 
to initiate a trade. 

25 The system 10 further provides the functionality to permit the trading of 

various financial instruments via an auction function, as generally illustrated in a 
flowchart 600 of FIG. 29. The system performs what is referred to herein as a 
two way Dutch auction with credit preferences. In this auction methodology, 
users submit orders into the auction giving both the price and the quantity at 

30 which they wish to trade, as indicated by block 602. The auction process then 
begins by calculating the price at which the most volume is traded, as indicated 
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by block (04. This is called the auction-price. The auction-price is a fair price 
at which all transactions will be completed. In this calculation, the credit 
preferences of the various counterparties are not yet taken into account. At block 
606, the system matches up orders such that aU credit preferences are taken into 
5 account such that the minimum number of tickets are generated. The better 
submitted prices have priority, and all orders at the auction-price are preferably 
filled in proportion to each other. In a preferred embodiment of the auction 
feature, the auction process could be conducted a few times a day in order to 
maximize liquidity. The system also offers the functionality to enable the user to 

10 trade forward rate agreement switches and other switch products in an auction 
environment similar to that described previously. 

The system then automatically generates a confirmation for each 
u^nsaction and sends it electronically via email, fax, or another means to die 
counterparties of each executed transaction, as indicated by block 608. This 

IS unique confirmadon process has been designed to use a standard and consistent 
format for all financial instruments. 

At this point, a more detailed description of the operation and 
functionality of the auction mechanism 34 is provided. With refereiK:e to FIG. 
30, the auction mechanism 34 initially receives an order list from those traders 

20 wishing to participate in an auction, as indicated by block 620. The orders 
within the order list are separated into a BuyList and SellList, as indicated by 
block 622. At block 624, a price list is generated and sorted from highest price 
to lowest price. It is then determined at block 626 whether an auction will take 
place by detennining if the price list is ^xnpty. If the price list is empty, then no 

25 auction takes place, as indicated by block 628. If the price list is not empty, then 
die average auction price is calculated, as indicated by block 630, and as 
described in greater detail with reference to FIG. 31. Next, the orders are 
matched such that the minimum number of tickets are generated, taking into 
accoimt the credit preferences of all parties, as indicated by block 632, and as 

30 described in greater detail with reference to FIGs. 32A and 32B. Once the 



-92- 

SUBSHTUTE sheet (rule 26) 



W099/19«21 



PCT/US98/215I8 



orders have been matched, a setdetnent list is generated, representing the 
execution of transacdons via the opdon, as indicated by block 634. 

With reference to FIG. 31 , the average auction price is calculated. In 
particular, beginning at block 640, the initial parameten are established, such as 

5 i=ij = l,differenceequalsl-bl.k=2, and N=size of price list. In addition, 
the total amount in the BuyList is B|, and die total amount in the SellList is S^.^ 

. Next, it is determined at block 642 whettier k=N+ 1. If so, flien the 
average aucdon price is P, If it does not, then it is determii^ at block 644 
whether difference is greater than 0. If it is, ttien parameter j is set to j =j + 1 , 

10 the parameter difference is set to difference = difference + B, and the parameter 
k is set to k=k + 1, as indicated by block 646. If not, then the parameter i is set 
to equal i=i+ 1, die parameter difference is set to difference = difference +Si the 
parameter k is set to k=k+I, as indicated by block 646. The stq)s of block 642- 
648 are repeated until determination is made at block 642 that k=n+ 1 . 

15 With reference to FIG. 32, the step of matching orders in an auction is 

described in greater detail. In parucular, items in die BuyList and SellList are 
eliminated according to the average aucdon price, as indicated by block 650. It 
is then determined at block 652 whether die size of BuyList is greater dian zero 
and the size of SellList is greater than zero. If one or the odier is not greater 

20 than zero, then the setdement list is generated, as indicated by block 654. If both 
the BuyList and SellList are greater than zero, then die parameter Bsum is set to 
equal the total volume in BuyList and Ssum is set to equal die total volume in 
SellList, as indicated by block 656. It is then determined at block 658 if Ssum is 
greater than the Bsum. If it is, then the parameter listl is set to equal SellList 

25 and the parameter list2 is set to equal BuyList, as indicated by block 660. Next, 
the oiderl parameter is set to equal to the first order in listl and orderl is 
removed from listl, as indicated by block 662. The maximum/minimum and 
credit rules are dien applied to search the BuyList for matching order2. A 
matching order2 is located and a trade is generated between orderl and order2, 

30 as indicated by block 666. If at block 668 it is determined diat Ssum is not 
greater than Bsum, dien parameter listl is set to equal BuyList and list2 is set to 
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equal SellList, as indicated by block 668. Next, orderl is set to equal the fint 
order in listl and orderl is removed from List!, as indicated by block 670. 
Next, iist2 is searched in order to find a match to orderl using the maximum- 
minimum rule and the credit preferences associated with the orders, as indicated 
5 by block 672 and described in greater detail with reference to FIG. 33 . A trade 
is then generated between orderl and order2, as indicated by block 674. 

With reference to FIG. 33, the application of the maximum-minimum rule 
and credit rules satisfying an order are described in greater detail. Initially, it is 
noted that the parameter volume is equal to the vohmie of an order, and more 

10 particularly, of orderl. At block 680, it is initially determined whether the 
parameter volume equals 0 for orderl . If it does not equal zero, then it is 
determined at block 682 whether list2 is empty. If iist2 is not empty, then list2 is 
searched for the first matching order, as indicated by block 684. Once a 
matching order is located, then the volume traded will equal to the minimum as 

15 defined by the credit preferences of either party, the volume of orderl, or the 
volume of order2, as indicated by block 686. It is then determined if the trade 
volume is 0, as indicated by block 688. If the trade volume is 0, then the process 
begins again at block 680. If the trade volume is not equal to 0, then a trade is 
generated and placed in the settlement list, as indicated by block 690. In 

20 addition, at block 692, order2 is removed from list2. Next, the volume of orderl 
and order2 are updated by setting the respective volumes to the previous volumes 
minus the trade volume, as indicated by block 694. It is then determined at block 
696 if the volume of order2 is equal to zero. If it is not, then order2 is placed 
back in a temporary list and a credit of the parties placing orderl and order2 are 

25 updated, as indicated by block 698. Once the volume of orderl is determined to 
be zero, then it is determined at block 702 whether the temporary list is empty. 
If it is not, then the temporary list is merged with the BuyList. as indicated by 
block 704. Subsequently, the process ends. 

The operation of the central processing center 12 is now generally 

30 described with reference to FIG. 34 which functionally depicts the group server 
mechanism 32, the auction mechanism 34 ard switch mechanism 35, the market 
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inventory module 38, the execution module 40. and the settlement module 42. A 
legend 710 is provided to the denote the flow of the different orders, interactive 
and switch orders, auction orders, and switch auction orders, between the group 
server mechanism 32, the auction mechanisms 34. the market inventory module 
5 38, the execution module 40, and the setdement module 42. Beginning with the 
interactive/switch order generated by the user at one of the trader workstations 
20, the central processing center 12 initially receives the interactive/switch order 
712 at the group server mechanism 32. At the gtoup server mechanism 32, an 
order record is created, the credit preferences of the users are checked to assure 
10 the trade conforms to the current credit preferences of the users, and a 

transaction order is created. If the order is passive, then it flows through to the 
market inventory module 38 where is it distributed to the trader workstations 20 
for viewing via respective market detail interfaces 302 of the users logged on the 
system 10. If the order is active, then it flows through to the market inventory 
15 module 38 where order matching occurs if the order is a part of an auction, and 
pie-execution of the order also occurs. Pre-execution may include, for instance, 
a back-end credit check to ensure up to date credit preferences and to 
accommodate con?)lex checks. Further, in a manner that is transparent to the 
users, the market inventory module 38 requires the trader workstations 20 of the 
20 respective users that are a party to the trade to respond with an acknowledgement 
to assure that there has been no loss of communication or that one of the users 
has not logged off. Upon receiving the acknowledgement, the market inventory 
module 38 executes the trade and then publishes the updated volume and status to 
the users logged on to the system 10 for viewing via respective command center 
25 interfece 130 of the users. 

Next, the execution module 40 will, upon request of one of die users that 
were a party to the trade, enables the quantity of the orade to be increased via the 
will-do-more feattire. This will typically be die case unless the full quantity of 
the instrument is transacted. Otherwise, the execution module will initiate the 
30 confirmation process which includes an oppominity for either of the users that 
were a party to the trade to enter into term negotiations. 
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The Older the flows through to the settlement module 42 which initiates 
the setdem^ process. The setdement module allows for symbol explosion by 
the users to view the exact terms of die contract. Further, a setdement module 
calculates the commission based upon the order which ends the process » thereby 

5 noting the end of the order execution process. 

In the case of an auction, an auction order 714 received by the auaion 
mechanism 34. The auction module 34 enables auction and switch auction 
functionality of the present invention. The auction module initially receives the 
auction orders 714 a from a plurality of users during a countdown to the actual 

10 auction time. Once die auction time has arrived and the auction orders have been 
submitted, the auction mechanism 34 performs the auction matching with credit 
preferences of die users taken into account. The auction matching performed by 
the auction mechanism 34 is in accordance with the present invention, that is, the 
auction is based on a fair price and executed for a maximum volume traded with 

15 a mtntmiim number of tickets generated. From die auction mechanism 34, once 
tl^ counterparties have been matched the market inventory server essentially 
treats the resulting auction orders as though it would an interactive/switch order 
712. In particular, die market inventory module 38 perform order matching, pre- 
execution, acknowledgement, trade execution and volume/data publishing. 

20 The auction order 712 is dien delivered to die execution modide 40. At 

die execution module 40, an auction order and a switch auction order are traded 
slightly different. For instance, an auction order may be increased in quantity by 
one of the users that is a party to the auction order via the will-do-more. On the 
other hand, switch auction orders do not make use of this feature, but will go 

25 directly to the confirmation process. Further, where auction orders may also 
have their non-commercial terms negotiated using die term negotiation feature, 
switch auction orders will flow to die setdement module 42 direcdy after 
confirmation. Bodi auction orders and switch auction order are then received by 
the setdement module 42 which performs essentially the same operations to the 

30 auction order as it does to an interactive/switch order 712. Specifically, die 
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settlement order 42 provides similar explosion and commissioned calculations 
which complete the order process. 

In the drawings and specification, there have been disclosed typical 
preferred embodiments of the invention and, although specific terms are 
5 enq)loyed, they are used in a generic and descriptive sense only and not for 
purposes of limitation, the scope of the invention being set forth in the following 
claims 
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CLAIMS 

Wherefore, the following is claimed 

1 . A system for fsicilitating derivative trading, comprising: 

a communications network operationally intefxx)nnecting a first trader and a 
5 second trader to a central processing center; 

a market module associated with said central processing center that 
provides said first and second traders with essentially real-time order information 
regarding more than one financial instrument, said order information including 
requests to buy financial instruments and requests to sell financial instruments; 
10 a trader module associated with each of said first and second traders for 

receiving said real-time order information fi"om said central processing center and 
presenting said real-time order information to said first and second traders 
according to trader customized profiles; 

a credit preference module associated with each of said first and second 
15 traders, said credit preference modules indicating trade eligibility of respective said 
first and second traders for each of said requests to buy and said requests to sell; 
and 

an execution module associated with said central processing center that 
processes a trade initiated by one of said first and second traders >\4iich desires to 
20 trade on an order posted in said order information by the other of said first and 
second traders. 

2. A system for facilitating derivative trading, said system haying a 
plurality of interconnected trader nodes that exchange order information, each 

25 trader node comprising; 

a trader module that receives real-time order information and presents said 
real-time order information to a trader according to customized profiles defined by 
said trader; 

a credit preference module that includes credit preference data inputted by 
30 said trader for use in determining trade eligibility of trades proposed in said real- 
time order information with a second trader; and 
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an interface to a communications network that interconnects said plurality 
of trader nodes. 

3. A system for facilitating derivative trading, said system having a 
S plurality of interconnected first and second traders that exchange order 

information, each of said fust and second traders cormected to a central processing 
center, said central processing center comprising: 

a maricet module that provides said first and second traders with essentially 
real-time order information regarding more than one financial instrument, said 
10 order information including requests to buy financial instruments and requests to 
sell fmancial instruments; 

an execution module associated with said central processing center that can 
process a trade initiated by one of said first and second traders which desires to 
trade on an order proposed in said order information by the other of said first and 
15 second traders; and 

an interface to a conmiunicattons network that interconnects said plurality 
of first and second traders to said central processing center. 

4. A method for facilitating derivative trading between a first party and 
20 a plurality of potential traders including a second party, all of vAdch are 

intercotmected by a computer network, said method comprising the steps of: 

inputting credit preference data on the potential traders for distribution to 

the potential traders; 

sending an order fix>m the first party to the potential traders requesting a 
25 trade on an instrument; and 

receiving an acknowledgment from the second trader initiating a trade with 

the first trader on the order. 

5. A method for facilitating derivative trading between a first party and 
30 a second party, comprising the steps of: 
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receiving an order from the first party to the second party requesting a trade 
on an instrument; 

checking the order for trade ehgibility based on credit preferences of the 
first and second parties; 
5 encoding the order with the appropriate information based on said step of 

checking the order; 

presenting the encoded order to the second party based on a preference of 
the second trader to receive orders on the instrument; and 

initiating a trade between the first and second parties if the second party 
10 initiates a trade. 

6. A method for conducting electronic trades of financial instruments 
over a computer based system, comprising the steps of: 

receiving order data into the computer system, wherein said order data 
15 includes a proposed trade of a financial instrument, and wherein the financial 
instrument is defined by a symbology comprismg a source field, a class field, a 
symbol field and a currency field distributing the order data to potential traders; 
and 

presenting via the computer system the proposed trade to at least one 
20 potential trader utilizing the symbology. 

7. A system for conducting electronic trading between traders, 
comprising: 

means for entering order data, herein said order data comprises a financial 
25 instrument defined by a symbology comprising a source field^^ a class field, a 
symbol field and a currency field; 

means for distributing said order data to traders; and 
means for presenting said order data to at least one trader utilizing said 
symbology. 

30 
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8. A system for credit screening an electronic trade of a financial 
instrument between a first trader and a second trader, comprising: 

means for receiving first credit preference information of said first trader 
with respect to said second trader, wherein said first credit preference information 
5 relates to at least one financial instrument; 

means for receiving second credit preference information of said second 
trader with respect to said first trader, wherein said second credit preference 
infonnation relates to at least one financial instrument; 

means for evaluating said first and second credit preferences with respect to 
10 a trade of a first financial instrument to determine respective trade eligibility of 
said first and second traders to trade with each other; and 

means for reporting said respective trade eligibility to said first trader and 
said second trader. 



15 9. The system of Claun 8, wiierein said means for reporting includes a 

first indication representing that said first and second traders will 
trade with each other, a second indication representing that said first 
trader will trade with said second trader but said second trader will 
not trade with said first trader, and a third indication representing 

20 that said second trader will trade with said first trader but said first 

trader will not trade with said second trader. 



10. The system of Claim 8, wlierein said means for reporting includes a 
color coding scheme for presenting said first, second and third indications 
25 respectively to said first and second traders. 



11. A method for screening order information proposing a trade of a 
financial instrument via an electronic trading system, comprising the steps of: 

receiving first credit preference information defined by a first trader with 
30 respect to a second trader; 
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receiving second credit preference information defined by the second trader 
with respect to the first trader, and 

encoding the order infonnation that is presented to the first and second 
traders proposing a trade utilizing the first and second credit preference 
5 information. 

12. The method of Claim 1 1 , fiirther comprising the step of modifying 
the first credit preference information by the first trader. 



10 13. The method of Claim 1 1 , wherein said step of encoding includes a 

first indication representing that the first and second traders will trade with each 
other, a second indication representing that the first trader will trade with the 
second trader but the second trader will not trade with the first trader, and a third 
indication representing that the second trader will trade with the first trader but the 

1 5 first trader will not trade with the second trader. 

14. A system for risk portfolio management that enables switches 
between traders, con^rising 

means for receiving risk position portfolios associated with respective said 
20 traders; 

means for calculating relative positions for each of said risk position 
portfolios associated with respective said traders; and 

means for presenting said relative positions to respective said traders. 

25 15. The system of Claim 14, wherein said means for presenting 

presents to a fust trader at least one possible switch combination with a second 
trader based on respective said risk position portfolios associated with said first 
and second traders. 

30 16. The system of Claim 14, wherein said means for presenting 

presents to a first trader at least one offsetting position in said risk position 
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portfolio of said first trader which corresponds with a position in said risk 
position portfolio of a second trader. 

17. A method for risk portfolio management utilizing an electronic 
S trading system, wherein said electronic trading system includes a plurality of 
traders operationally connected, said method comprising the steps of: 

receiving a risk position portfolio from at least a first trader and a second 
trader from the plurality of traders; 

calculating relative risk positions of each risk position portfolio received 
10 from the first and second traders; 

matching offsetting relative risk positions of the first and second traders, 
thereby executing a switch; and 

updating the risk position portfolios of the fist and second traders based 
on the executed switch. 
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